Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-03-24 14:20:35

Edward Diener <eldiener_at_[hidden]> writes:

> On 3/22/2012 5:11 PM, David Greene wrote:
>>
>> 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.
>
> While automatic merging of any single language source code file may
> actually work and produce output that is correct, I personally would
> never trust it without having to manually check it.

You should always check the result of a merge -- that applies to both
centralized and decentralized version control.

> This is why I object to the advantage which is claimed for DVCS
> systems that merging being done better with them ( presumably because
> local commits are part of the history when pushing to another
> repository ) is some great advantage.

The claim is that DVCS merge better than centralized tools. I've already
described that the ability to to merge well isn't tied to being
decentralized or not. It just so happens that you merge more often in
decentralized tools and so these tools have had to invest more energy
into making merging work really well.

Subversion now has merge tracking -- it should therefore be able to do
merges as well as Mercurial and Git. However, it still doesn't handle
simple cases like merging changes into renamed files:

  http://stackoverflow.com/a/2486662/110204

To repeat: the problem is not that SVN is centralized, the problem is
bugs and unhandled corner cases in its merge support. Git and Mercurial
don't have these bugs and so we say that they merge better.

Btw, the local commits have nothing to do with merges: (in Mercurial) a
three-way merge is based on the final result of the branches you merge
and the intermediate steps are irrelevant.

>> 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 update or commit without access to an SVN repository, but
> this has nothing to do with restricting access to any part of an SVN
> repository, which is a no-brainer in SVN.

I think the point was that SVN requires you to work with a branch in the
central repository. A DVCS allows (but doesn't require) you to work with
a branch that you keep local and truly private.

You're suggesting that this can be done with SVN too by creating the
branch in the central repository and then restricting read and write
access to it? Yes -- that is possible, but it's not a natural way to
work with SVN. I also think you need to involve the SVN admin unless you
can edit the access control rules yourself.

-- 
Martin Geisler
Mercurial links: http://mercurial.ch/