July 11, 2013
The question of "which version control software is best?" is right up there with "What is art?" and "Is vim better than emacs?". Actually these days it boils down to Git versus Mercurial. Everyone has forgotten about SCCS and RCS (or should have). CVS was fine until SVN came along. SVN was the hot fish up till about 2005 or so, but is now clearly fading into the gloom.
This leaves us with Git or Mercurial. You can find intelligent people favoring either one and giving good reasons why they feel the way they do. Git has an impressive track record and I have found no reason to use Mercurial instead, so I am going with git.
If you want to, you can read about some of the pros and cons in these articles:
There is also now something called "bazaar" or maybe it is "bizarre". I am biased against it because it is yet another doggone version control system clamoring for our attention. Just say no! Ignore it. No doubt somebody somewhere, right now is writing yet another piece of version control software. And more people are lining up behind those people.
GIT is the 900 pound gorilla of version control. It was written by Linus to support linux kernel development. It has over 100 commands, and complexity is probably the leading reason more people do not use it. It turns out this is a bad reason, but keep reading.
Git makes two big advances over SVN:
In 2011 I began fiddling with GIT. I have found that it is actually quite reasonable to deal with. A small set of commands do everything that I want. I have tested the claim that branching actually works, and found it to be true. So far I am very impressed.
Take a look at this analysis of GIT and Mercurial done by Google in 2008.
To learn git:
Here is a partial "cheat sheet" showing command equivalents (more or less).
Subversion (SVN) |
Mercurial (Hg) |
Git |
|---|---|---|
| svn add | hg add | git add |
| svn blame | hg blame | git blame |
| svn cat | hg cat | git show |
| svn checkout | hg clone | git clone |
| svn commit | hg commit ; hg push | git commit -a ; git push |
| svn delete/remove | hg remove | git rm |
| svn diff | hg diff | git diff, git diff –cached |
| svn help | hg help | git help |
| svn log | hg log | git log |
| svn revert | hg revert | git checkout -f |
| svn status | hg status | git status |
| svn update | hg pull –update | git pull |
| svn move/rename | hg move/rename | git mv |
There are people out there who claim that you should never use git pull, but always first fetch, then merge. I blindly followed this advice for a while, but now I just pull and am lazy and happy.
Nobody uses CVS or RCS anymore. At least nobody (except an idiot) would use these systems by choice for a new project. Anybody inheriting some old project using these would convert them to git or mercurial and would curse the lazy slob who had not already done the conversion.
I will ashamedly admit that I have some projects still under CVS.
In comparison to CVS, using SVN is like stepping into the 20th century. But not the 21st century, you need git or mercurial for that.
For simple linear workflows with one developer, SVN is fine, and as a bonus it will handle binary files (but don't try to merge changes). In fact whatever you do, do not try to branch and merge with SVN, you will deeply regret it.
Here is my set of notes about how to use SVN.
Like GIT, mercurial is a distributed version control system (DVCS) and has a branch and merge system that works.
Mercurial is written in python, which is neither here nor there unless you are crazy enough to want to modify it or write extensions.
To learn Mercurial:
I have a set of notes about working with TRAC which you might find useful.
TRAC is strongly SVN oriented, although there are GIT and mercurial plugins. There are probably better web front ends to a git repository such as Cgit or redmine. There are even plugins for using multiple mercurial repositories inside of Trac, which makes me happy.
Here is an article you can read.:
Tom's Computer Info / tom@mmto.org