Re: [boost] [git] Mercurial?

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

On 03/21/2012 11:02 PM, Julian Gonggrijp wrote:
> 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.
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. Though, as has been pointed out numerous
times now, every approach comes with its own set(s) of problems.
>> 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?
No, I am saying that altering history is dangerous! Which you described 
as one
of the advantages of "the git approach". I completely lost track. I 
described
my experience I had with. I was told that this was not the way to go, I 
am not
sure if it is directly related to "changing history". But the problems 
existed.
Now, force pushing (as i understand this is the only way to rewrite 
published
history) essentially breaks every other clone of that public repository. 
This
is exactly the can of worms I am referring to.
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.
Or to formulate it differently: When is my public repository, which i 
intended
for my use only, not private anymore?
>
> -Julian
>
>
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost