Re: [boost] [git] Mercurial?

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:

  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/