40
votes

This is more a discussion question than an actual attempt to determine the "best", since that clearly varies by the needs of the organization. I'm more curious about the arguments in favor of different systems across categories (centralized vs distributed, open vs proprietary, etc).

So, what do you think is the best version control system?

4

15 Answers 15

79
votes

Mercurial

Because of it's sophisticated ability to branch and merge code, it is the best I've used. The whole DVCS paradigm just makes so much sense. I've not used Git, but I suppose that it qualifies as well.

6
  • I've got to try out Mercurial some time since I've already tried 2 of the big 3. And since Google Code supports it...
    – TheLQ
    Sep 5, 2010 at 5:11
  • 2
    Mercurial is sweet if you're using Netbeans. the IDE integration is perfect.
    – Seun Osewa
    Sep 16, 2010 at 19:06
  • 4
    I prefer Mercurial simply because TortoiseHg is more mature than TortoiseGit :-) (the whole experience on Windows is much better in Mercurial as well) Oct 12, 2010 at 3:21
  • +1, I suggest making Mercurial bold and bigger (as Gaurav did in his answer)
    – user131
    Dec 13, 2010 at 12:57
  • Mercurial is pretty sweet. Me and my team have been using it for about 2 months and it's a breath of fresh air compared to SVN. Mar 7, 2011 at 21:37
72
votes

Git

Git's fantastic, and I would particularly recommend it to anybody working on open source projects: it's a lot easier to contribute a small, one-off change to a project on Git, especially if its hosted on GitHub, than it is dealing with e-mailing patches about with SVN.

One big caveat for Windows users: Git's Windows tools, though definitely useable, aren't quite up to scratch. When I was forced to use Windows for a while, I tried out Mercurial's Windows interface with an Hg-Git integration tool so I could use my Git repositories, and found that a lot easier to use.

13
  • 5
    I think is important to say that git is hard. I really love it, but it's not something you can use learning it on a couple of days. You have to use it for a while and get angry until you mind switch... ;-)
    – Khelben
    Sep 27, 2010 at 14:44
  • 1
    @Khelben - There is some truth in that, yes. However, it also does seem to have the greatest amount of literature/articles/tutorials on the net dedicated to it. I regularly find Git books coming out, Mercurial - not so much (using Mercurial here as a contrast, since it's in many ways similar to Git). Can't say whether that's good or bad, but it does seem people are using it.
    – Rook
    Sep 27, 2010 at 15:19
  • 2
    msysgit is usable under Windows.
    – user1249
    Dec 12, 2010 at 19:55
  • 1
    I assume that git, Mercurial etc are all quite good, but i went for git mostly because auf GitHub. GitHub feels nicer than comparable sites and many important projects are hosted there. GitHub lowers the barrier to contribute to Open Source a lot. Dec 13, 2010 at 9:00
  • 2
    Mercurial doesn't NEED a book.
    – Warren P
    Jun 17, 2011 at 1:39
24
votes

Warning: Since this post I've found Mercurial and love it much better than SVN. So this post is a bit out of date with the Pro SVN comments and general anti-DVCS, but the anti-git stuff is still relevant


I'm a fan of SVN over Git.

Why? Because SVN was much easier for a single developer or small team, and git (specifically msysgit) left me with a bad taste in my mouth.

When I was interning at a small shop, I was introduced to git on Windows. I immediately noticed the amount of work it took to get it to work with Github. First, I had to generate a ssh private key, paste the public key in Github, then bring up pageant and open my private key each time I wanted to push, which was extremely annoying.

And I never really liked that I was pulling down the entire repository. I will admit that I never worked with anything huge, but I would be afraid to download KDE's repository in Git if the entire repo and its revisions are on my HD.

Then there was the confusing process to make a commit. TMK, I had to first "stage" all the files I wanted to commit (which sucked when you had many many files, took me a while to find the manual command to stage everything), then do the commit, then push to the main repo (why is that a separate operation?!).

You also had the not(!) very helpful commit data. Oh look, this is commit 14f74433245ae17aeeaa part of tree 2167a4934d0a4a7db0de and parent d7042abb4821d3faf600. The hell does that mean? I should be able to figure out things pretty quickly and not have to consult some weird documentation.

Speaking of documentation, at least when I was using it, it seemed everything was in linux man file format, IE confusing and useless to me. I rarely could find much help in the docs and simply resorted to google.

And with commits, the one thing that I didn't like was the lack of version numbers. Now I know that this is because of the design of git, but any software needs a version number. I still remember the marker commits that would pop up saying "Changed version to 1.8.6" or something similar, but you still couldn't do build numbers. To me having the version be 1.8.6.5164 (last part is revision number) tells me a lot more than simply 1.8.6 and a note saying that something minor changed, try it

Getting software specific, the base program on Windows is msysgit, which is a terrible interface. It locked up on me a few times, had a horrible interface, and CLI-GUI integration was iffy at best. The command line junkies around me hated the gui even more.


Now lets look at SVN. And since I'm on Windows and have a google account, specifically TortoiseSVN and Google Code.

First, complete shell integration to do everything on the repository (and for you linux people, RabbitVCS does the same thing), no main GUI needed. Getting a repository is easy as a checkout, no SSH needed (can't remember if Github required SSH for pulls), and no entire repo + all past commits sitting on your HD.

Committing is extremal easy, mainly because no SSH or staging is required. You simply check all the files you want using the very helpful select all option that in my msysgit version wasn't available, type in a commit message, and hit commit. Google Code then asks you for your login information (which most clients store), and your done. Simple, easy, and no SSH

Version numbers? With some easy code, you can add a version number and a commit number to all checkouts, which makes things so much easier. You also get usable version numbers that actually show a change, eg 1.8.6.5165 is newer than 1.8.6.5164.

Documentation? Well, its hard to say. Tortoise is documented, but I haven't actually referred to the official documentation in such a long time that I can't judge. Reading a simple intro guide was enough for me.

Merging is something else I can't compare. I had to do it once in Git when somebody else committed a change to a file I was working on, but never in SVN.


Which one would I recommend? Well in large teams, git does have its advantages, mainly in its non-linear development cycle. In another project I saw 4 programmers start in separate branches, then merge all the code in very strange ways that somehow morphed into the final master branch. Github and msysgit had a really nice visualization tool for the whole project that I really liked.

For single developer or small team projects, SVN would be the best since most of Gits features aren't used and your only getting its negative parts. Simplicity is such a nice thing

28
  • 6
    Merging with SVN is quite risky (compared with git). That's one thing that it's important to note on any comparison.
    – Khelben
    Sep 29, 2010 at 11:09
  • 5
    Why do you need to "bring up pageant" every time? It's a key agent. You only have to bring it up once, when you log onto your machine. You add your key, and you're done. (And you can make it even easier by associating your keyfile with pageant and adding that to your startup folder. Log on, it pops up with the dialog prompting you for your passphrase.) Oct 10, 2010 at 7:37
  • 3
    @Thorbjoern @Frank Shearer: I think the very fact that you're saying "you can do this, or you can do that, and not have those issues" highlights the point: Those are solutions to a problem or an issue. It's a non-issue with some other VCS'. Dec 12, 2010 at 21:32
  • 4
    This answer strikes me as a lot of complaining and moaning about something that the poster clearly did not take the time to understand. I've spent extensive time in both git and svn, on both linux and windows, and will testify that git is vastly superior to svn, in concept, data model, understandability, and usefulness.
    – gahooa
    Dec 13, 2010 at 2:15
  • 4
    @TheLQ No. It's not "your Linux mentality" at all. It's a simple thing to set up, it's well documented, PuTTY is an excellent Windows application suite that makes things really really simple to use. And you really should be encrypting your code transfer, if you're working through any public network. And it's insulting to Windows users to assume they're too stupid to learn how to use the tools they should be using. I'm not asking people to shell into things. I'm asking them to encrypt their important info. Dec 13, 2010 at 15:55
21
votes

The following quote from Q4TD pretty much sums it up for me:

“I loved Git until I tried it. Now I love Mercurial.”

        — Tor Norbye, The Java Posse Podcast

Also, hgsubversion makes a pretty good subversion client for Linux (where I usually use the command line, unlike Windows where I usually use TortoiseSVN). The biggest advantage: no .svn sub-folder in every folder, just a .hg at the top level.

Update: In response to Alex's request in the comments to "say more about why git didn't work for you, and how Mercurial worked better":

I wouldn't say that Git doesn't work for me, but Murcurial does work better IMO.

In a nutshell, this is Mercurial:

alt text

and this is Git:

alt text

And I assert that Mercurial will do everything most developers will need it to do, without having to look up the manual to figure out how to do the everyday things.

Admittedly, I've only used Git occasionally, but the programming community has been going gaga over languages like Ruby and Python, in part, for their conciseness and elegance, whereas Git feels like a camel that was designed by a committee of camels.

Bah, now look at what you've done? There's rant all over the place. Move along, nothing to see... nothing to see...

Update 2: And another apropos tweet I just came across:

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.”

6
  • Ever tried RabbitVCS?
    – TheLQ
    Sep 12, 2010 at 4:22
  • No, but I use KDE, not Gnome so it wouldn't suit me anyway. I will occasionally use a graphical SVN client on Linux, but only really when doing something a bit esoteric like exploring a repository or comparing previous revisions. Not for the simple add/remove/commit/log stuff. Command line is faster.
    – Evan
    Sep 12, 2010 at 13:43
  • 2
    Could you say more about why git didn't work for you, and how Mercurial worked better? That'd be pretty interesting to read. Dec 13, 2010 at 0:06
  • I'm pretty sure the Git depiction is missing a 6" long straight razor ...
    – user131
    Dec 13, 2010 at 12:59
  • 2
    @Tim: rebase? It's probably on the other side. Dec 13, 2010 at 14:25
14
votes

I don't have a single "best" version control system, but rather a single best VCS paradigm.

I have used multiple different centralized version control systems and multiple different distributed version control systems. And I can say without hesitation that noone should ever inflict a CVCS upon themselves.

I don't care which DVCS you choose (my particular favorite is Git), but please do yourself a favor and use a DVCS. For one: you will be much more flexible. DVCSs can trivially emulate a CVCS workflow (just never fork the repository, and treat your local repositories only as a chache instead of an independent fork), whereas the converse is impossible. And while logically, doing this emulation should carry some overhead (and indeed it does), I still find it easier to use (not to mention much more performant due to the local caching) than any of the CVCSs I have used.

2
  • 3
    This is a great answer. There isn't any one "best" VCS, but I agree totally that one should be using a DVCS. Sep 16, 2010 at 17:01
  • Make mine a DVCS, but hold the homeomorphic endofunctors mapping submanifolds of a Hilbert space, please. Ergo, Mercurial.
    – Warren P
    Jun 17, 2011 at 1:35
11
votes

Can't say that I've encountered the Best version control software, but I can tell you to stay away from VSS and MKS. Both are dogs that should be avoided at all costs.

7
votes

I wouldn't say the best, but one with very interesting features and concepts.

Fossil is a distributed version control, bug tracking and wiki project built on SQLite database as repository.

5
votes

Team Foundation Server

Because:

  1. It's a good, solid VCS. (I wouldn't consider it the best by any means, but it has nice extras.)
  2. Its built in task and bug tracking that integrate into Visual Studio helps me stay focued and know what I need to work on all in one place (automatically applying a check-in to a bug or task and closing it is pretty good, though you can get plugins for other systems/eclipse/etc to do this.)
  3. It integrates tasks/bug tracking/projects directly into Project Server so I rarely ever have to keep project plans or timesheets up to date. Updates to the Project in Project Server automatically filters down as tasks into TFS and into Visual Studio for me to see automatically.
3
  • 2
    I'm curious as to how you felt about your workflow being constricted to exclusively Visual Studio for pretty much all development work. Also, did you have to do any of the infrastructure setup for TFS? My experience was opposite of yours in this way: #1 - VCS was not easy to use, often was flaky, and offline mode was created by satan himself. #2 The built in task and bug tracking was cumbersome compared to other tools, so #3 was irrelevant for us and created duplicate work. I've used it 3 different times now with the same bad results each time.
    – Jordan
    Mar 7, 2011 at 7:48
  • 1. I agree with offline mode sucking. I've not had many problems at all online, though, but I'm always connected. Many of the VCS controls, especially with folder remapping are actually hidden deep in the menus. Is that the problem you're having? 2. It is definitely more cumbersome, but saves work overall for my team integrated with Project server. 3. How does it create duplicate work? Are you duplicating the tasks in project server and TFS? There is an open source plugin for 2007 and a beta for 2010 that lets them sync with each other.
    – Ryan Hayes
    Mar 7, 2011 at 14:32
  • 1
    It did constrict me to VS, but we're a totally .NET shop. I use TFS with my Java projects at home, though. Try SVNBridge at svnbridge.codeplex.com which lets you use Tortoise with TFS. If you use Tortoise (like most Java, ruby, non-.net folks) then it should help you with your workflow in other projects.
    – Ryan Hayes
    Mar 7, 2011 at 14:39
4
votes

I have used a multitude of version control systems in my long history:

  • RPPT - (Rolls of Punched Paper Tape). In a shoe box. I'm not kidding.
  • PVCS - (Polytron Version Control System). The first real VCS I used.
  • SCCS - so long ago, I don't remember any thing exceptionally good or bad about it.
  • RCS - as others have pointed out, would rather suck sweaty donkey balls.
  • CVS - it was only a pain when used with more then 2 programmers. best feature: rcs2cvs.
  • VSS - it works, except on tuesdays, when it corrupts your entire repository.
  • Perforce - costs more than my car. The VCS itself is acceptable, but the dickhead IT guys that control every aspect of using it will never land it on my "preferred" list.
  • SVN - branching and merging is a bitch, but in general it is better than any of the previous. Not so good with lots of tiny outstanding changes awaiting review.
  • Mercurial - what little experience I do have with it, I like. I might try it on my next project.
  • Git - never had the opportunity to use it.

Although a couple were horrors, most were "fine". They didn't get in my way. As long as a tool doesn't make my life significantly more difficult, I don't really mind.

The real thing is to understand the strengths and weaknesses of each. Understand the target environment:

  • distributed or local
  • small team or large
  • hosted vcs service or not
  • easy integration into other tools

Joel also came out with an important observation: Learn the tool and its true model of use. He struggled mightily trying to make Mercurial behave like Subversion.

5
  • 1
    If only the comment on VSS was a joke... avoid like the plague.
    – DevSolo
    Oct 12, 2010 at 1:56
  • Ah, PVCS, the memories that brings back:) What a piece of junk that was.
    – Henry
    Dec 12, 2010 at 21:50
  • That list reminded me of the language based "shooting yourself in the foot". +1
    – Orbling
    Dec 12, 2010 at 22:21
  • I do remember bad things about SCCS, but it was generally usable. I do remember trying to do simultaneous work on files with SCCS and other programmers, and that's why I fell in love with CVS when I saw it. Dec 13, 2010 at 16:52
  • Visual SourceSafe, A VCS especially for programmers who want to gouge out their eyes with spoons.
    – Mark Booth
    Apr 27, 2011 at 13:39
2
votes

One newer system that we use at my office is Plastic SCM (http://www.plasticscm.com/). It works very well for our small team and gives us some great control over every aspect of source management.

1
vote

SCCS.

Or, if you happen not to have been living a cave for the last 38 years, CSSC.

Seriously, my company is using TeamWare, which is a kind of pseudo DVCS based on SCCS.

No, I'm not kidding.

Sun switched to mercurial from TeamWare only a few years ago. Now you should understand why Java seemed to move so slow.

1
vote

MPW: Well, I can't really give it a review in spite of my efforts.

This was back when I was learning programming in high school, and the only really free C++ compiler to be had was Macintosh Programming Workbench, which I kept on a zip disk and popped into whichever Performa was available in the lab.

MPW came with dozens of tools (none of which were resedit, that was a separate download), and one of them was a version control utility. It popped open a small window with a single line of text, and you were to drag and drop your projects or files onto it. It had no documentation that I was ever able to discover, unusual considering everything else seemed to have great docs, and so I never quite worked out how to use it.

That was my first brush with VC, and the last one for a good long while. Now I use git for everything.

1
  • Projector! At a part time job during college I used a (tricked out) version of that. Good times.
    – RyanWilcox
    Dec 13, 2010 at 1:12
0
votes

RCS - Revision Control System

Solo coding made so easy.

5
  • You are kidding, right Xepoch? Please god be kidding.
    – Marc W
    Sep 17, 2010 at 19:19
  • You guys are making me laugh. Actually I DO use RCS but ONLY for my personal websites, &c. I was half-way kidding about using it for major development, BUT I have seen it exclusively used (rather than CVS) on shared development Unix systems. Honestly, we had no problems with it at all, but does NOT lend itself to anything other than a single server feature.
    – Jé Queue
    Sep 17, 2010 at 19:37
  • 1
    @Xepoch, you might be better off learning Git or Mercurial- DCVS works great for solo development. Sep 17, 2010 at 20:15
  • 1
    You know what the really nice thing about RCS is? You can put all your RCS ,v files in a proper directory structure and you've got a CVS repository almost ready to go. There's plenty of tools then to convert from CVS to any modern system you like, such as Mercurial. Sep 27, 2010 at 14:44
  • @Xepoch, the ease with which to back up distributed vcs'es is unbeatable.
    – user1249
    Dec 12, 2010 at 19:58
0
votes

Not ClearCase, at least for a Unix/Linux system (perhaps with Windows the installer is easier). It was easier for me to learn a new tool, Perforce, rather than upgrading our ClearCase server.

I currently use Perforce at work and I like it but I have no idea if it is the best. Setting up the command line environment and the Perforce Server is a bit awkward, but using the Visual Client is fairly easy. I like to think the users have a fairly easy time with it for everyday tasks; it is just the initial setup takes some work.

0
votes

I have used Visual SourceSafe and hated it, but it was better than nothing, but not by much. For the last couple years, used something called QCVS by Qumasoft.com written, owned and supported by Jim Voris the programmer. Simple gui, cheap price, good support.

Just does the job.

Not the answer you're looking for? Browse other questions tagged or ask your own question.