Edward Diener <eldiener@tropicsoft.com> writes:
On 3/20/2012 7:03 AM, Julian Gonggrijp wrote: ... snip
Well, allow me to present some fair reasoning to you.
With regard to git versus svn: I think enough fair reasons have been given why git (or a DVCS in general) is better than svn. I'm not going to repeat those arguments here.
I have never heard a single technical argument, in all the endless mentions of Git among the people riding that bandwagon, why Git is better than SVN, or even why any DVCS is better than a centralized SCCS. I consider this whole move to Git and/or DVCS among "hip" programmers little more than a move to conform with what others are doing and feel "cool".
I'm trying to sell Mercurial consulting, so I've also been searching for such an argument -- I need some concrete benefits to show to clients! One very concrete and important difference between Mercurial and Subversion is support for renames while merging. SVN 1.5 to 1.7 has a bug that makes it difficult to merge a branch with renamed files: http://stackoverflow.com/a/2486662/110204 You might say "That doesn't really have anything to do with DVCS" and you would be right! There's no reason why a centralized tool couldn't be super smart about merging. I think it's an indirect effect: a DVCS *must* be good at merging since there are lots of branches. Centralized tools can get away with having bugs here and there since there are fewer branches. As I see it, the main effects of a DVCS (Git or Mercurial, doesn't matter much here) are: * very fast access to data -- it's right there on your harddrive * private branches -- you can work offline, don't have to share immediately That's the immediate consequences of the D in DVCS. But what I like to stress are the secondary effects: * more useful history: since you have fast access to the history, people tend to use it more. Things like the bisect command in Git and Mercurial is a good example: it lets you do a binary search on your history to see when a bug was introduced. You could certainly do this with a centralized tool, but it's more expensive since you have to checkout data from a central server. * smaller commits: when commit takes a fraction of a second, people tend to commit more often. This makes the commits focused: there will be one commit with a fix to a comment, another commit with a new feature, and another commit with an update to a test. Smaller commits are easier to review and this leads to *better code*. * better commits: when you don't have to share your commit with the rest of the world, you suddenly have a chance to refine it. Both Git and Mercurial allow you to edit your local commits before pushing them to a public repository. This means fewer followup commits where you actually add the new file you intended to commit before... I hope this helps a bit. -- Martin Geisler Professional Mercurial support by aragost Trifork http://www.aragost.com/mercurial/