40

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?

yannis
  • 39,597
Fishtoaster
  • 25,919
  • 1
    http://en.wikipedia.org/wiki/Comparison_of_revision_control_software is a great comparison table for exactly this. Discussion question... community wiki ? – Chris Sep 17 '10 at 18:50
  • 4
    The first who posts the name, gets the rep… This should be community wiki. – takeshin Oct 11 '10 at 18:16
  • @takeshin: No. See http://meta.programmers.stackexchange.com/questions/8/purpose-of-community-wiki and http://meta.programmers.stackexchange.com/questions/333/what-to-do-with-community-wiki – Fishtoaster Oct 11 '10 at 19:20
  • Didn't notice this is already a Community wiki. – takeshin Nov 02 '10 at 11:33

15 Answers15

79

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.

epotter
  • 2,846
  • 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 05 '10 at 05:11
  • 2
    Mercurial is sweet if you're using Netbeans. the IDE integration is perfect. – Seun Osewa Sep 16 '10 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) – Dean Harding Oct 12 '10 at 03:21
  • +1, I suggest making Mercurial bold and bigger (as Gaurav did in his answer) –  Dec 13 '10 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. – Gary Willoughby Mar 07 '11 at 21:37
  • What drives me nuts is that people seem to want to stick on "standardizing" on something awful, instead of using something lovely, amazing, and great. I am trying, with no luck, to get people to even care about the question, "what should we use?". Sigh. – Warren P Jun 17 '11 at 01:38
72

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.

Gaurav
  • 567
  • I recently told a former coworker that I was in love with Git and I meant it. I regularly use SVN and Mercurial and like them but I love Git. – chauncey Sep 09 '10 at 21:18
  • 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 '10 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 '10 at 15:19
  • 2
    msysgit is usable under Windows. –  Dec 12 '10 at 19:55
  • I'll agree that git on windows is a bit clunky, but I can't seem to find any way in which it is actually lacking compared to running it on a linux box. – SingleNegationElimination Dec 12 '10 at 20:14
  • I still haven't 'got' git yet. Branching and merging is cool but everything else is clunky. – Henry Dec 12 '10 at 21:45
  • 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. – LennyProgrammers Dec 13 '10 at 09:00
  • 1
    git sucks on windows, has a ridiculous learning curve and having to run cleanup on the repo is just lame. – Tim Jan 23 '11 at 05:31
  • 1
    I've only started using git just recently, but I have to say I'm quite the fan. I've used RCS, CVS (urgh to both of those), SVN, bzr, and now git... and while there was a bit of a learning curve to git, it wasn't anything that couldn't be solved with a few searches on SO. And it seems to actually be quite hard to kill a git repository - even with all my shenanigans, I haven't managed to, yet... – sevenseacat Jan 26 '11 at 14:00
  • Having gone CVS -> Subversion -> Git in the last seven years, each transition has brought huge improvements. Git is much more robust (keeps everything on every machine), fast (mostly because of the distributed nature) and intuitive (but only after a while). Better docs, colors by default, cherry-picking (especially with git gui) and GNU Tools support don't hurt. – l0b0 Jan 26 '11 at 14:23
  • For anyone using emacs, it takes about 5m to be productive in git and 1h to master more advanced features. I think git is the standard VCS for open source projects. – Leo Jan 27 '11 at 03:28
  • I wouldn't say git was hard for me to learn. I came from CVS/SVN background, so it was easy for me to pick up git in a day (I learnt by starting a small project for myself and doing git init on it and went on the next day with pushing my changes to a repository in a backed up drive). I've noticed users of SourceSafe and ClearCase that need to relearn everything they know about version control having issues with it. – Spoike Mar 07 '11 at 07:51
  • 2
    Mercurial doesn't NEED a book. – Warren P Jun 17 '11 at 01:39
24

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

TheLQ
  • 13,580
  • There's an ad on Stack Overflow that I keep seeing: "Git on Windows sucks. git# needs your help"(see: http://meta.stackexchange.com/questions/53346/open-source-advertising-sidebar-2h-2010/54328#54328 )". I think that's your main problem, git doesn't suck as much on other platforms. – imgx64 Sep 12 '10 at 02:34
  • TortoiseGit. It is your friend. – Frank Shearar Sep 20 '10 at 12:16
  • 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 '10 at 11:09
  • 1
    Requiring SSH isn't a big deal... I wouldn't really say its much of a negative. Cygwin works good for ssh. It also sounds too much like your yelling at Git for not being SVN. Git is not SVN. You have to completely forget about SVN to use git, otherwise it doesn't make sense. – alternative Oct 10 '10 at 00:10
  • @mathepic The thing is, I learned Git before I learned SVN, so I had no previous bias. It was only after I learned SVN that I found out how much Git sucks. And SSH is a big deal when you have to constantly bring up pagent or use Cygwin just to do a commit, and SVN just has simple username and password authentication. – TheLQ Oct 10 '10 at 02:37
  • 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.) – Frank Shearar Oct 10 '10 at 07:37
  • 1
    Precisely the opposite experience here. I find GIT much easier to work with, solo or in a group. I worked at a place that used SVN, and all I can say is I'm glad git-svn exists. – Inaimathi Nov 19 '10 at 18:29
  • eval $(ssh-agent); ssh-add as the first command in your msysgit session does wonders. –  Dec 12 '10 at 19:56
  • 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'. – Steven Evers Dec 12 '10 at 21:32
  • I agree with pretty much everything you said. Why is it so hard to commit something!? – Henry Dec 12 '10 at 21:48
  • 1
    @Frank Shearar: The problem is that most Windows users rarely use SSH at all, unless they are web devs and have to manage hosting. As a consequence they do not have Pageant running, don't really want it running from start up, etc. Also, I agree with @SnOrfus. – Orbling Dec 12 '10 at 22:16
  • @TheLQ not saying that msysgit has the greatest UX, but sounds like you've got some really poor setup for your SSH. I just have to type in my passphrase in bash the first time I run it in a Windows session. As this question is community wiki, would the answer be more suitable with griping removed? – Armand Dec 13 '10 at 01:27
  • 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 '10 at 02:15
  • @SnOrfus What issue is that? It's like the horse-rider complaining that to drive a car you need to start the engine. It's really not an issue with the program at all. (And yes, I do think that every single programmer on earth needs to know how to use SSH.) – Frank Shearar Dec 13 '10 at 09:23
  • Do you live near a nuclear reactor? –  Dec 13 '10 at 12:57
  • Lets address these one at a time: @gahooa Just because the model and idea's are superior doesn't mean anything when usability is crap. SVN takes a maximum of 5 minutes to get working on Windows. Git takes hours, even days, to get working. I thought I wrote my post like this: If your a simple person, use SVN. If your a large complicated group, then spend the time getting Git working since its better in the long run. It still doesn't hide the fact that Git sucks in Windows, and Linux people refuse to do a native port – TheLQ Dec 13 '10 at 15:37
  • @Thorbjørn I'm pretty sure that won't get executed if I run purely the GUI. I could be mistaken however – TheLQ Dec 13 '10 at 15:38
  • 1
    @Alison Git has two options: Plink and SSH. Both are highly recommended. I was introduced to Git with Plink, so I used that. Later I needed to use SSH, but when I tried to get my existing key to work with SSH, it constantly failed. I spent weeks (months?) off and on trying to get it to work. My final solution involves Cygwin, different key locations, and duct tape. It was hell to get it to work, but it works. Its really the only way to use SSH with existing keys – TheLQ Dec 13 '10 at 15:44
  • @Frank Things should work out of the box. Its like shipping your car in pieces with some parts missing or wrong, then having to use your Linux mentality of Google + random poking to get it working. Git works great in Linux, sucks in Windows. – TheLQ Dec 13 '10 at 15:47
  • 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. – Frank Shearar Dec 13 '10 at 15:55
  • 1
    @SnOrfus, saying that "git over ssh is a pain" because ssh needs to be configured, is hardly gits fault. To my understanding, git can use a shared folder instead which circumvents all these problems. See http://progit.org/book/ch4-1.html –  Dec 13 '10 at 16:05
  • 1
    @Thorbjørn @Frank Shearer: Software inherits the pains of its dependencies, so any problem with SSH is a problem with git if it uses it. SVN uses SSL just fine, without any problems. For the single or very small dev team, it really is a great solution - preferable to git IMO. – Steven Evers Dec 13 '10 at 16:32
  • @SnOrfus, great for you :) We just happen to need the ability to work without access to the central server occasionally. Thats easy with a distributed system, but needs vary. –  Dec 13 '10 at 20:46
  • @Frank So if Putty works so well then why do I get this error: http://stackoverflow.com/questions/4221631/ . Or when I want to use my existing private key I get this: http://stackoverflow.com/questions/1556119/ Putty helps but is not a permanent solution. Besides, its a work around. If the Linux community would actually make a native port of Git to Windows instead of emulating through MinGW, 90% of all the problems would go away. And just as @SnOrfus said, SVN (and Mercurial) work just fine over SSL. And if someone is intercepting your commits, you have other problems – TheLQ Dec 14 '10 at 00:35
  • 2
    @TheLQ I'm sorry to read of your problems. You don't need cygwin to use PuTTY. TortoiseHg installs with it out of the box requiring a single line change to the ini file. TortoiseGit was a teeny bit trickier for a shared repository, but again nothing that a few minutes' googling couldn't fix. As for "if someone is intercepting your commits, you have other problems" - yes, and it's trivial to prevent someone from doing so, isn't it? Encrypt your sensitive data. – Frank Shearar Dec 14 '10 at 09:08
  • SnOrfus, you can also do TCP/IP with carrier pigeons, and run git over that, but that would also be tedious. The usage of ssh to access a git repository is the choice of the git repository administrator and refers to a problem outside of raw git - git in itself just makes it easy to use ssh as the transport. –  Jan 26 '11 at 13:44
  • 2
    This whole discussion is a false dichotomy, git and svn are not the only options – jk. Mar 07 '11 at 13:26
  • Try Mercurial, sir – dukeofgaming May 26 '12 at 03:35
21

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.”

Evan
  • 1,392
  • Ever tried RabbitVCS? – TheLQ Sep 12 '10 at 04: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 '10 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. – Alex Feinman Dec 13 '10 at 00:06
  • I'm pretty sure the Git depiction is missing a 6" long straight razor ... –  Dec 13 '10 at 12:59
  • 2
    @Tim: rebase? It's probably on the other side. – Alan Pearce Dec 13 '10 at 14:25
  • I use both git and hg, and I'm leaning towards hg because of better tool support at the moment (on gasp Windows). – Spoike Mar 07 '11 at 07:46
14

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.

Jörg W Mittag
  • 103,514
  • 3
    This is a great answer. There isn't any one "best" VCS, but I agree totally that one should be using a DVCS. – Nick Hodges Sep 16 '10 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 '11 at 01:35
11

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.

Walter
  • 16,146
7

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.

Maniero
  • 10,806
5

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.
Ryan Hayes
  • 20,129
  • 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 07 '11 at 07:48
  • 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 07 '11 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 http://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 07 '11 at 14:39