Boost logo

Boost :

Subject: Re: [boost] [git] Mercurial?
From: David Greene (greened_at_[hidden])
Date: 2012-03-22 17:11:02

Edward Diener <eldiener_at_[hidden]> writes:

>> Also back to the point - DVCS are written to provide best possible
>> support for merging. This makes 1) or 2) you propose above very
>> efficient. In SVN or other centralized systems it is not so, just look
>> up the bit I left from Joel's message above.
> I do not believe for even a second that any product can do merging of
> the same source file automatically and flawlessly.

This strawman keeps resurfacing.

No one has claimed than any VCS can avoid manual merging at times.

A centralized VCS needs to operate as you outlined:

>> Bu how is this different from:
>> 1) Creating a local SVN repository and importing some branches from
>> another SVN repository.
>> and/or
>> 2) Having one's own branch of an SVN repository as one's own.

#1 is a horribly manual operation. I don't know if you quite grasp how
complicated it is. I've been doing it for years. Getting the history
preserved correctly is not trivial.

#2 has almost no support in SVN. Now that SVN has merge tracking it is
marginally better but there are problems with this model. Foremost, the
branch has to be in a centralized repository and everyone owkring on the
project has to deal with it in some fashion. It's not private in any
sense of the word. You can't work on it if you don't have 'net access.
You can't back out changes that you realized later were bad and ensure
no one else ever sees those changes.

The difference with a DVCS is both #1 and #2 are natively supported in
the tool. There is no difference between a private local branch, a
remote branch in a _de_facto_ central repository and a remote branch in
some other random repository. They all look and act the same.

I admit it is a tough concept to grasp for someone not used to it. It
took me some time to grok it. But now it is second-nature to me and
there's no way I'm going back.


Boost list run by bdawes at, gregod at, cpdaniel at, john at