Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-03-21 18:02:22

Thomas Heller wrote:

> On 03/21/2012 04:56 PM, Julian Gonggrijp wrote:
>> [...]
>> 
>> The second argument is more technical, and perhaps more convincing.
>> It works even without branches or collaborators. All we need is a
>> single developer who makes some changes to their working copy of a
>> project.
>> 
>> [...]
>> 
>> Result: the units-of-work developer is spending less time to get the
>> same thing done with less opportunity for errors.
>> 
>> Note that the pieces of history that tend to get altered in a units-
>> of-work model generally don't make it into version control in a
>> snapshot model at all.
> 
> Sure, this all makes sense. Except that failures often only materialize
> _after_ you made your changes public. [...]
> So, to repeat, this all sounds nice and dandy, but after digging deeper,
> it doesn't sound like it is generally applicable.

This is not just about bugs or private/public, this is about making 
changes to work. Even just changing your mind before you make 
something public already happens often enough to make local unit-of-
work commits a feature. If a bug is found after the faulty code has 
gone public, small commits still help to better narrow down the 
changes that caused it and to reduce the amount of work that has to 
be done to solve the issue.

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.

> Unless you can test
> _everything_ on your local machine, or you push onto a volatile branch,
> which opens a completely other can of worms (from what i understand).

What can of worms? I don't recall reading any post that described a 
can of worms associated with volatile branches. Besides, /if/ you're 
altering volatile branches anyway, that's again way easier to manage 
with unit-of-work commits than with snapshot commits.

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?

-Julian