Poll: Version Control

https://news.ycombinator.com/item?id=326683

by wtrk • 18 years ago

43 90 18 years ago

news.ycombinator.com

GuyE• 18 years ago

Subversion

apgwoz2• 18 years ago

I adopted mercurial when git was "painful" to use. It seems as though this has changed, but I see no compelling reason to switch just because all the Rails kids think git's cool right now.

jmtulloss3• 18 years ago

I love mercurial because it's so painless. It just works. Everywhere.

KirinDave• 18 years ago

Mercurial's metaphor for local branching is awkward. Git's metaphor is not, and most people go batty for it. That's a pretty good reason to change.

I wouldn't use git if it didn't have cheap inline local branching. It is the Killer Feature.

apgwoz2• 18 years ago

> Mercurial's metaphor for local branching is awkward.

That may be true (honestly, I don't know), but I haven't yet needed to maintain different branches of projects I'm working on and so it's a non-issue at this point. If at some point it becomes an issue, and I find Mercurial lacking, then of course I'll take a closer look at git, who probably does it more appropriately.

silentbicycle11• 18 years ago

Mercurial also has cheap local branching, though to my understanding it is easier to close out branches that have been merged back in / abandoned on git. The mercurial developers are working on this, though.

vito2• 18 years ago

I used mercurial briefly and found it to be much, much slower compared to git.

silentbicycle11• 18 years ago

Under what OS, hardware platform, filesystem, project size, etc.?

Not knee-jerk arguing, genuinely curious. When I compared them on Windows and OpenBSD, I never had a speed difference of more than about 5% (not counting git db repacking), even with a project that had 40,000+ commits, 10+ very active branches, and about 2 GB of code + data.

jrockway2• 18 years ago

all the Rails kids think git's cool right now

A stopped clock is right twice a day.

silentbicycle11• 18 years ago

It doesn't matter if they understand what's actually cool about it, of course. (http://news.ycombinator.com/item?id=327085)

MicahWedemeyer• 18 years ago

I'm trying very hard to like git, being a Rails kid coming from the svn world. Still, besides the kickass merging, everything else seems ass-backwards.

Remote work especially is bonkers. Push/pull? Easy. Add/Delete remote branch? Off to google for me...

there• 18 years ago

i'd like to know why people are using what they are. did you pick git because you just recently started using version control or was there really something you needed in it that made you switch?

i've been using cvs for about 10 years now and have no reason to switch to anything else. it does what i need without any extra fluff, all my projects are in cvs, and the majority of the projects i contribute to use cvs.

nihilocrat• 18 years ago

Using bzr: our development is done in Python, so it's handy to be able to a) modify things if we need to and b) bundle bzr with our company's python install.

It was the first distributed VCS I have used. I highly suggest it for personal or small projects, as it supports "dumb storage" and thus you can host a repo anywhere you have ftp or sftp access. It is also handy for working around annoying firewall restrictions where you can't really checkout code the way a centralized system does.

aston• 18 years ago

Mercurial's also in Python. And I think in most benchmarks it comes out ahead of Bazaar. Might be worth a look.

silentbicycle11• 18 years ago

Using mercurial -- it and git seem significantly better than the rest, but when I recently test-rode them both, mercurial felt like it worked better cross-platform, and the overall design felt cleaner. Git would be my second choice, and I'm sure github and the network effect will do a lot to popularize it.

(I've read several blog posts in which people try git and are absolutely thrilled, but in almost all cases they were previously using CVS or SVN.)

FWIW, I had been using Monotone for a while, but mercurial seems quite a bit simpler in day to day use.

llimllib2• 18 years ago

git because I was able to introduce it gradually, due to its great svn integration. We just switched to it fully last week.

I love DVCS because I get to keep the code on my computer version-controlled, and the power of branching, merging, and cherry-picking is awesome once you get used to it.

pmjordan• 18 years ago

For new projects I'm using git rather than subversion. I normally develop on my desktop system, but when I'm on the go I use my laptop. Subversion isn't useful for that kind of scenario if you don't have constant internet/network access. With git I can do commits, look at the history, etc. even when I'm on my laptop and offline. (you can keep copying the whole repository with svn but that pretty much defeats its purpose)

I'm pretty new to git though, and I haven't even touched the more advanced features.

nostrademons2• 18 years ago

I switched from CVS to SVN because I needed to rename a bunch of directories, and that's so incredibly painful in CVS that I might as well start a new repository.

I switched from SVN to git because I needed to work offline for a week, so I gave git a try (initially, I had my project versioned under both systems) and liked it so much I stuck with it.

aaronblohowiak2• 18 years ago

using subversion over cvs because of repository revision numbers, renaming of files.

using git over subversion because of sane branching / merging / rolling back, history tracking, SPEED, increased redundancy (everybody is backing up the repo!) and local commits.

elai• 18 years ago

Speed, non-idiotic operations (rename, branches) and offline commit's

potatolicious• 18 years ago

I use a combination of git and Subversion. SVN for the main repo that is shared between developers (with many developers working at once the lack of atomic commits really sucks), and git as my own offline versioning system. The code that I write tends to go through several iterations, and I'm loathe to commit anything to SVN until things work well enough to please me. Bad code should never make it into your prod repo, but I'm not a fan of rewriting/deleting mass chunks of code without SCM to back me up.

jaxn• 18 years ago

Ok, this convinced me to at least give git a try. I made the move to SVN from CVS years ago to be able to rename / move stuff in the repo, but the offline version control would keep me from keeping a bunch of updates in a branch uncommitted while I do a major push.

My current offline version control system has been leaving all the files open in TextMate to take advantage of undo/redo. (Horrible I know).

eggnet• 18 years ago

We were using svn for a while, but micromanaging the individual files turned out to be too tedious for me to introduce to our group.

git add .

git commit -a

yes, it's two commands but in return git will automatically find new files, internally delete files you have deleted, and even automatically find renamed files (under most conditions).

I don't have a great argument about why we chose git over mercurial, it seemed like the right choice. But I can tell you that git is a lot better than svn for our purposes.

I find it somewhat funny about the complaints of git being difficult to use. Personally, our team found svn difficult to use due to having to micromanage moves adds and deletes.

edit: also, not having a bunch of .svn directories peppered all over your directory structure is nice, just one .git directory at the top. You can move directories in and out from other locations without worrying about anything.

mihasya3• 18 years ago

Selling points to convert me from SVN to Git: * single directory * ease of setting up a local repo * per-line commits (interactive mode)

etal2• 18 years ago

I introduced Bazaar at my new research lab, with good results. Our requirements were:

1. They're scientists who need to do some programming, rather than programmers who need to do some science, so the command line is acceptable but confusion and complexity are not.

2. Remote hosting is not kosher. Dunno, there are rules, apparently there was a bad experience once and the NIH got involved.

3. Everyone has their own work to track, but project ownership can be fluid. Another guy should be able to seamlessly take over one of my projects without losing the history, and with 30 seconds or less of over-the-shoulder explanation on how to do it. If an operation requires significant manpage investigation, they'll probably get impatient and just use scp.

4. None of the machines is expected to be on all the time. The network will almost always be available, but we all have laptops, too, so offline work ought to be possible.

5. Speed isn't a big issue; our machines are suave and everything's on a LAN.

Subversion would be OK if we had a designated server that's always on. But we don't. Git has the low-level design figured out a little better than Bazaar, but the plumbing commands are confusing and I couldn't figure out how to make a shared repository temporarily act like it's all centralized, and I worry that a Windows user might come in and spoil the party.

As far as features go, git, hg, bzr and darcs borrow from each other like crazy; the differences are mainly in developer priorities and culture. Bazaar's team cares about documentation and usability above all else, which is what I care about too, here, so that's what I went with.

bayareaguy• 18 years ago

fossil

graywh2• 18 years ago

The first thing I thought of was a version control system that only lets you make one version; then it's etched in stone for all eternity.

So, maybe it's a bad choice for a name, but the system itself sounds interesting--it includes a wiki and bug tracking.

kingkongrevenge2• 18 years ago

Multiple daily backups produced by rsync using hardlinks works well when revisions are too drastic and frequent to give a meaningful history. version control will just get in the way of one or two people drastically refactoring a young project.

rcoder2• 18 years ago

I have to respectfully disagree here. Having super-lightweight branching and local commits has helped me greatly, even in the tumultuous early days of a new project. Basically, it gives me the freedom to create a branch, hack for a while, and then either pull the changes into the trunk or abandon them, while still keeping an easy "bookmark" in place (a.k.a. the branch itself) to go back and review later.

Using rsync may offer a history of your code, but without any associated semantics, you're dependent on your own memory and grep to actually find out why a change was made. Making commits intentional, and associating them with a particular task, will greatly simplify your code archeology later. Rest assured, some day you will need to figure out why certain decisions were made, and your memory won't be complete (if it was even you who made the decision the first time).

Furthermore, adding a ticketing system from day 1 really helps impose a useful type of discipline onto your process. Work to be done is described in a ticket, and the ticket identifier gets referenced in your commit messages. Much like basic version control discipline, having a record that associates change requests with units of work will help keep you sane down the road.

kingkongrevenge2• 18 years ago

> create a branch, hack for a while

$ cp -R project testbranch

> then either pull the changes into the trunk or abandon them

diff or rm -rf. And none of the nuisance of explicitly telling the VC system when you're adding, deleting, and renaming files.

Harkins• 18 years ago

FWIW, multiple backups and hardlinks are the basic foundation of git. Running 'git commit -a' a few times a day to check in all the changes isn't a big timesink; commit messages can take time or not depending on how detailed you care to be.

I've has some personal projects that were 'moving too fast' for version control, or that I was just playing around with. In every case I ended up losing code because I couldn't remember how I'd done something I'd later removed. And I've never had a project with more than one copy of the codebase -- whether that's a local dev and a production deployment, or two devs -- that didn't end up overwriting code or config at some point.

It's not surprising that version control, largely useful for history, does not appear to be immediately useful for a young project. But young projects become old projects with the same habits and practices. Start with good ones.

bestes• 18 years ago

I use git because the low-level design is rock-solid and simple enough for me to understand. I also like distributed version control for the work alone and on a team aspect. This does not mean git is easy to use or that I'm even very good at it, BTW.

johnm• 18 years ago

Why do these polls get repeated so regularly? http://news.ycombinator.com/item?id=323041

graywh2• 18 years ago

Because not all of them make the front page? And even if it did, this person probably missed it. Really, is that so wrong?

wtrk• 18 years ago

Sorry! I follow HN primarily through the RSS feed and a lot of posts/threads never show up there.

Before posting, I did Google for polls on the subject of version control and didn't turn up anything (oddly enough, this thread seems to be at the top of the results page):

http://www.google.com/search?hl=en&q="version+control"+poll+site:news.ycombinator.com

Even if I had seen your poll, though, I probably would have posted anyway because I'm interested in getting a feel for how many people use some of the systems that are listed at top besides Git, Mercurial, and Subversion.

ulysses• 18 years ago

Also, that poll had much fewer choices.

For that matter, this one doesn't have plain old RCS, which is what I use.

truebosko• 18 years ago

All projects right now use Subversion except one new project at home that I decided to try Git out with.

All projects at work though use Subversion for now, but I am the only developer. (Just makes it easy to revert incase of issues as our system deals with a lot of numbers)

I like Git .. it's very fast and simple to use :)

ph0rque• 18 years ago

Git for hacking projects, DropBox for personal files (which makes for interesting arrangements, since the git repos are in my personal files).

jcromartie• 18 years ago

I know from experience that git is superior, but I still use svn because it is the (modern) Lingua Franca of revision control. TortoiseSVN on Windows also gives it a definite advantage on that platform.

silentbicycle11• 18 years ago

Tortoise is also available for mercurial. (http://tortoisehg.sourceforge.net/)

timtrueman• 18 years ago

Can anyone with experience with both SVN and Git comment on the pros/cons of branching and merging (this is something I do often in Perforce). Which would you use based on this one issue?

llimllib2• 18 years ago

svn's complete lack of merge tracking is simply too painful to use. git will make you much happier.

rgilmour• 18 years ago

svn as of 1.5.0 does support merge tracking. I must admit that when first looking into svn I was very surprised to find that it did not originally support it.

silentbicycle11• 18 years ago

If branching and merging matters to you at all, switch to git or mercurial immediately.

You won't look back.

jrockway2• 18 years ago

I wrote a somewhat long article about Git merging:

http://blog.jrock.us/article/Git%20merging%20by%20example.po...

cookiecaper• 18 years ago

Git. It's extremely fast and featureful and I don't care about interoperability. Much faster than SVN or anyone else. Linus writes great software.

jmtulloss3• 18 years ago

It's only a little bit faster than mercurial, and the size of the repository is larger.

notauser• 18 years ago

I have a 250gb hard disk, and no spare minutes per day.

silentbicycle11• 18 years ago

Also, the project maintainers seem to place a very low priority on portability. People work on Windows, BSD, and OS X, too.

callmeed• 18 years ago

Using Git, Mercurial, and SVN ... for diff projects

mcargian• 18 years ago

Using bzr. A few months ago when evaluating bzr, git, and mercurial, the features were similar between all three, but bazaar won in the ease of use category.

barryfandango• 18 years ago

Team Foundation Server.

tlrobinson• 18 years ago

Git itself is growing on me.

GitHub is just awesome, especially for open source projects. (of course I say this just as GitHub goes down for the first extended period of time since I started using it)

"git bisect run" is incredibly cool for tracking down when a bug was introduced: http://tlrobinson.net/blog/?p=51

silentbicycle11• 18 years ago

Mercurial also has bisect, FWIW.

jsmcgd• 18 years ago

This article talks about VCS as if they were airlines.

You or may not find it helpful. Hope you do.

http://changelog.complete.org/posts/698-If-Version-Control-S...

rsobers• 18 years ago

Team Foundation Server.

wastedbrains• 18 years ago

Currently on SVN switching to git soon, just don't have the time at the moment. git looks like the best choice, and if I was starting anything new I would start with git now.

ced2• 18 years ago

None. From where I stand, it seems like extra management duty, for marginal benefits.

eru2• 18 years ago

Have you tried it? Version control makes you braver in deleting and rewriting.

ced2• 18 years ago

No. Whenever I go on a tangent, I just make a copy.

I do AI, maybe that's the difference. Honestly, apart from utils.lisp, I wouldn't cry much if I suddenly lost all my files. Code is trivial, the important point is in the experience / insights.

I'll try it some day for sure. It's just not that appealing. It was the same with Emacs.

kalid• 18 years ago

If you find your self with directories like "v1" "oldv1" "updateD!!!" you need version control :). Subversion has GUI clients integrated into file explorers so you don't even notice the overhead.

I wrote more about it here, if you'd like convincing:

http://betterexplained.com/articles/a-visual-guide-to-versio...

joestrickler• 18 years ago

It's not. I spent a week setting up and learning to checkout, update, add files, and commit. The only workflow change is an occasional trip to the shell to commit, but this is usually at the very tail of a session where it doesn't break flow anyway.

Then (if you put in on a public server, of course) your work is accessible from anywhere. Run into a friend at Starbucks and want to show him the module you wrote today? Just get into the shell and checkout your repository.

Not only that, it's a perfect record of your project. Occasionally I need to assess the status of the project vis-a-vis some point in the past (for myself when strategizing, for my boss when he needs a report, etc). Being able to look at the commit logs saves time and produces better reports (commit logs don't forget).

So even if you use only the most basic features, you still get an immense benefit from using a VCS. And the hours it's saved me in trivial tasks made it well worth the week it took to hammer down.

13ren• 18 years ago

I have this feeling too. However, I've just started using git, and one nice thing is the sense of closure when you "commit" something, it's a milestone, a bit like a release. It's also nice to have a log of changes, with a short comment about each one.

But I haven't had any actual advantage from it so far; and any nervousness about playing around with files has shifted across to nervousness about playing around with the repository (I had to delete it and start again a couple of times). Actually, I find doing anything to the repository (reverting, branching etc) terrifying, because I don't really understand what it's going to do, and I could lose everything. If only there was a way to back it all up first... ;-) I'd rather just get on with my actual tasks! Just my experience - so far.

etal2• 18 years ago

Yes, git does have that effect at first...

I found the bzr documentation to be a great resource for understanding how DVCS (and even centralized VCS) systems are supposed to work.

http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html

And I like how bzr is willing to act like svn on demand. Setting up a shared repository is easy, other users can pretend they're using a centralized VCS as long as they need to, and when you eventually encounter a situation where distributed development would work better, not much really needs to change -- it's version control with no regrets.

I imagine learning git would probably be much easier if you were already familiar with bzr, since you'd already have a point of reference for most of the operations. The same way C is easier to structure if you already know a higher-level language like Python -- the abstract concepts are already familiar, so it's just a matter of translating them to another language, rather than figuring it all out from scratch in a pricklier environment.

aaronblohowiak2• 18 years ago

" I find doing anything to the repository (reverting, branching etc) terrifying, because I don't really understand what it's going to do, and I could lose everything."

Like many things in the software world, the more you know, the better off you are!

mihasya3• 18 years ago

uh.... what?

noodle2• 18 years ago

clearcase at work

subversion for my personal/startup stuff

ardit33• 18 years ago

my god. poor you. I had to use clearcase a while ago, and it was painful.

noodle2• 18 years ago

actually, i've not found it to be difficult to use, just not as slick, clean and intuitive as other options. not the best, but not exactly bad, per se.

eru2• 18 years ago

A friend and I agreed on Bazaar: Since he is working on Windows we could not use Git.

hapless• 18 years ago

Darcs' redeeming feature is that it's so, so, so easy to use. The documentation is clear and the system is simple.

Distributed version control just doesn't get simpler.

Unfortunately, it's not particularly portable and it's not particularly fast. The former I can blame on its dependence on ghc. The latter, I dare not.

toolong• 18 years ago

These all suck

Prrometheus• 18 years ago

Gmail, sadly.

mihasya3• 18 years ago

I recently switched most of my stuff to git (granted I don't have that much source to throw around, so it was pretty easy) and absolutely love it.

brlewis• 18 years ago

RCS - I'm coding solo and RCS has essentially zero setup.

donniefitz2• 18 years ago

I know it's not kosher to mention here but you forgot Team Foundation Server.

schtog• 18 years ago

Is it worth learning a version control system for small personal projects, say 10 source-files and 5-10 different versions?

I feel like I need something sometimes but most of the tools above seem a bit complicated and not very intuitive.

asmosoinio• 18 years ago

I use Subversion, and constantly check in my code. I love the feeling of control and permanence. 10 source files soon becomes 30, and 10 versions soon becomes 100 => Yes.

How often do you do a bigger change, then realize you still need some pieces of the previous version? Version diff to the rescue!

Poll: Version Control

Related Stories