Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-03-22 06:43:48

On 03/22/2012 11:32 AM, Martin Geisler wrote:
> Thomas Heller<thom.heller_at_[hidden]>  writes:
>
>> On 03/21/2012 11:02 PM, Julian Gonggrijp wrote:
>>> Thomas Heller wrote:
>>>
>>> Unit-of-work commits make it easier to find and review past work,
>>> reduce the burden on the developer to keep track of what they're
>>> doing until they're ready to publish it, and enable you to keep
>>> unfinished but versioned work around while working on other, more
>>> publish-ready changes. Unit-of-work commits really help you to manage
>>> and keep track of work, contrary to snapshot commits which mostly
>>> just provide a backup facility.
>>>
>>> This is way more generally applicable than you seem to be willing to
>>> admit.
>> Sure, this all makes perfect sense. But this is not restricted to a
>> DCVS, this can be done any version control system (be it centralized
>> or not). It is a matter of good habit.
> Indeed -- working in SVN or Git makes no difference here: you can (and
> should!) make small and self-contained commits in al systems.
>
>>> You seem to suggest in addition that what we've been discussing here
>>> has something to do with cans of worms. Do you actually intend to
>>> suggest that unit-of-work commits introduce problems that don't exist
>>> for snapshot commits?
>> No, I am saying that altering history is dangerous! Which you
>> described as one of the advantages of "the git approach".
> Altering local (=unpublished) history can be convenient. It's considered
> an advanced feature in Mercurial -- you need to enable extensions for
> this. Git has a *bias* towards more history rewriting since it comes
> with these features enabled by default -- but it's still frowned upon if
> you rewrite public history in git.
>
>> In the context of boost, as a loosly coupled organisation, where i
>> migh want to seemlessly switch, merge and whatever with other peoples
>> work, this looks a serious problem. This is exactly the can of worms i
>> was mentioning.
> It's not a serious problem in practice. DVCS sounds like anerchy at
> first, but it's not much different from a centralized setup. You have a
> main repository (possibly on boost.org) and things that are pushed there
> are by definition final/immutable/frozen: they've been published and you
> must assume that people depend on them.
>
> So you just don't rewrite those changes. If you push there and find a
> bug, then you do the same as in SVN: you make a new commit that fixes
> the bug.
>
> Collaboration with a DVCS is really a question of making incremental
> append-only changes to a code base. That hasn't changed much from
> centralized VCS. The D in DVCS does allows you to pull changes directly
> from Alice or Bob if you like. That can be convenient for working on a
> feature outside of the main repo. But when the changes go to the main
> repo, they are just as immutable as in SVN.
Right, makes perfect sense. I don't know what the plans of Dave Abrahams 
are, but if i remember he imagines a loosely couple collection of 
repositories of distincts libraries, where any of those is a potential 
candidate to either superseed an exisiting repository, or to be 
eventually be part of boost.
I don't know if i got that correctly, I guess it would be best to wait 
for Beman's talk to know the details here.
>
>> Or to formulate it differently: When is my public repository, which I
>> intended for my use only, not private anymore?
> In principle, it ceases to be private when you put it on a public
> server, tell others about it, and they begin basing their own work on
> your volatile changes.
>
> If you publish a repository on GitHub and tell me about then I might
> look at the commits there and give you feedback. If I'm not basing any
> work on the changes, then it's no problem if you later destroy the
> commits and even delete the repository.
Right, the *second* i hit the "fork" button on github, everyone sees my 
new repository.
>
> But if you push the commits to a main repository on boost.org you cannot
> just change your mind like that: you must expect that others will have
> pulled the changesets and the cat is out of the bag.
>