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
>> 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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk