Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-03-22 06:32:56

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.

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

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.

-- 
Martin Geisler
aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/