Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Edward Diener (eldiener_at_[hidden])
Date: 2012-03-24 11:34:17

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.

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.

>
> 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.

I agree with you it is not easy, but it is doable in SVN. I also agree 
that a DVCS system makes it normal and natural.

>
> #2 has almost no support in SVN.

I do not understand your remark, What is so hard in SVN of granting 
certain users access to certain parts of a repository, and how can you 
say it has 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 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.