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?
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.
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.
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
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:
and this is Git:
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.”
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.
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.
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.
Because:
I have used a multitude of version control systems in my long history:
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:
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.
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.
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.
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.
Solo coding made so easy.
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.
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.