Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Bronek Kozicki (brok_at_[hidden])
Date: 2012-03-21 05:02:20

On 21/03/2012 03:03, Rene Rivera wrote:
> On 3/20/2012 8:52 PM, Julien Nitard wrote:
>>> Related, I like to test branches and ideas without having anyone else
>>> observing my moves or caring about what I do; so, I can do that,
>>> locally,
>>> instead of creating obscure or sacred branches in SVN in a common
>>> repository.
>>>
>>
>> This is a very good point. Though it is still a specific need. The VCS is
>> here to help the team. If individuals want to play on their own, it's
>> only
>> "nice to have" IMHO and shouldn't make the other part of the process more
>> complex.
>
> I would argue that "hiding" changes is detrimental to software
> development. In particular it prevents sufficient software auditing and
> accountability. It would also curtail active review of the work such
> that it could end up that one would waste time pursuing development
> avenues that others have already discounted.

this is good point, but in practice I find it is just the opposite :) 
All members of my team have defined remote repositories of other 
members, and "fetch" these repositories daily. Sometimes they peek into 
the repositories without invitation, as one would read commits in shared 
repository. More often, they invite colleagues to review their recent 
work and, what's more important, any review feedback can be easily 
incorporated into private repository without creating confusion in 
shared one. Quite often the feedback (invited or not) is something along 
the lines "this file should not belong to this commit but that one, the 
commit comment is not clear enough, you obviously have an artifact from 
older version of code here". Making such changes in shared repository 
would create confusion, but thanks to editable history of private 
repository this really helps to keep shared repository clean and readable.

The result of this style is such that developers do commit often (and 
also run regression and unit tests often, as is habitual before every 
commit) and they also often look back at own and other's commits to 
ensure best quality of the final, shared result (which BTW is 
synchronized one-way to P4). Personally I find this style very 
empowering - I am not only free to experiment but can also rely on 
reviews from my colleagues. Or in other words, this style is more 
similar to writing a book than building a house. The history that you 
present to others is the one you intended, not the random result of your 
past mistakes and fixes. Others within your team have access (and are 
indeed invited) to see your mistakes, to help you improve the history 
before it is publicly presented.

B.