Subject: Re: [boost] [git] Mercurial?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-03-21 04:16:18
Edward Diener <eldiener_at_[hidden]> 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:
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
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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk