Subject: Re: [boost] [git] Mercurial?
From: Bronek Kozicki (brok_at_[hidden])
Date: 2012-03-21 05:55:43
On 21/03/2012 03:45, Edward Diener wrote:
> On 3/20/2012 10:56 PM, Joel de Guzman wrote:
... [BK snipped here]
>> From the beginning, Spirit had it's own community, mildly detached
>> from Boost. Spirit contributors come and go. We once develop code
>> using SourceForge (using CVS, then SVN). I give contributors
>> write access as needed. Once, stable, I move or merge the code
>> to Boost. It so happens that we had a more frequent release cycle
>> than Boost (at the time). Each move was soo frustratingly difficult
>> and time consuming (not to mention that I lose and never bothered
>> about the commit histories when moving code to Boost from SF; it
>> just was not worth the hassle. After all, SF was the master with
>> all the histories and the one in Boost was just a copy).
... [snip again]
> Yes, I recognize that
> psychologically the feeling that one has one's own local repository to
> play with, and then merge with other repositories, is enticing to users.
> Bu how is this different from:
> 1) Creating a local SVN repository and importing some branches from
> another SVN repository.
> 2) Having one's own branch of an SVN repository as one's own.
> What I object to about the DVCS people is that they seem to assert that
> because DVCS has a model they like, where there is no concept of a
> central repository, that this is automatically superior in some
> non-practical and perhaps personal way. I do not doubt that DVCS systems
actually there IS a concept of central repository in DVCS - it is the
one everyone else does "pull --rebase" from, and the one everyone else
does "push" to share their work. It's not all anarchy as some seem to
believe. The difference is that both "git pull" and "git push" are very
efficient (as efficient as e.g. "p4 sync"), and by default local work
does not require online access to central repository.
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.