Subject: Re: [boost] [git] Mercurial?
From: Edward Diener (eldiener_at_[hidden])
Date: 2012-03-21 18:57:58
On 3/21/2012 5:58 AM, Olaf van der Spek wrote:
> On Wed, Mar 21, 2012 at 4:45 AM, Edward Diener<eldiener_at_[hidden]> wrote:
>> I am pretty sure you can take an SVN repository and give users access to
>> whatever part of it you want while restricting access to the rest. When you
>> do that what is the difference from users having a DVCS to play with and
>> their own branch of an SVN repository to manipulate ?
> SVN requires the Boost repo admin to create accounts and set
I guess it takes a deep knowledge of molecular physics or string theory
to do that.
>> DVCS doesn't, as you can push to your personal branches.
>> Conceptually in my mind it is the same thing. 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:
> It's not about concepts, it's about practice. Do you have experience with DVCSs?
> If not, you probably don't fully understand their concepts and what
> they allow in practice.
Wonderful. I don't know because I don't have experience, but no one can
actually explain the technical benefits of these concepts.
>> 1) Creating a local SVN repository and importing some branches from another
>> SVN repository.
> Have you ever done that? How well did it work?
It worked with no problems. Why should it have problems ?
>> 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
> Lots of people have experience with DVCSs. They tell you the
> advantages are practical and real.
If I tell you that the advantages of standing on your head 4 hours a day
are "practical" and "real" would you find asking what this actually
means a strange thing to do.
>> perhaps personal way. I do not doubt that DVCS systems may have some very
>> good tools for merging together various local repositories into some other
>> one(s), but what does this freedom really amount to ? The end-user feels
>> better because it feels like one can work separately more easily and then
>> join one's work with others, but in reality a central repository system has
>> the same "tools". Furthermore merging work with others is NEVER as easy as
>> people would like to think it is. I am so tired of hearing about how all
>> this merging of code just automatically works, and works flawlessly. Who are
>> we kidding ?
>> I can understand your feeling of separating Spirit from Boost and then
>> joining back into Boost as you wish, and perhaps indeed a DVCS has better
>> tools to do this than Subversion, but can you really say this is a matter of
>> DVCS's being inherently better than a centralized SCCS in some way to enable
>> this ? How is this process different than merging whole branches or parts of
>> branches back into Subversion. However it is done merging is very hard and
>> careful work and it is impossible for me to believe that a DVCS has
>> something inherently about it that automatically makes it better.
> Why is that impossible to belief? Because you don't have any
> experience with DVCSs?
> Some VCSs really are far better at merging than others.
>> I guess I am saying that on a practical basis a DVCS may be more flexible
>> than a centralizes SCCS, but I see no inherent reason for this.
> So because *you* don't see the reason, others can't benefit from a DVCS?
I do not see the reasons because no one appears to feel it important
enough to actually enumerate them as technical arguments. All I get is
what I have gotten from you: "try it, you'll love it, because I do and
lots of others do." This is exactly what I wrote in my initial response.
I do not care about what others do, but I am not doing anything unless I
understand why I should do it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk