Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-03-20 23:50:17

On 3/20/2012 10:15 PM, David Bergman wrote:
> On Mar 20, 2012, at 11:03 PM, 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.
>
> Rene, it is not about hiding, it is about a thought process; of
> course one should make sure to (i) have a backup of such branches -
> but that does not necessarily have to happen via the version control
> system itself - and (ii) communicate when appropriate (which is not
> at every key stroke in my mental meta model.)

I didn't say anything about knowing your every action.. Although there 
are companies that would love to go into that much detail ;-)

>> In particular it prevents sufficient software auditing and
>> accountability.
>
> Wow

Is there more to that response?

>> 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. Because they would not see the path
>> you are taking and warn you about the cliff you are about to walk
>> off into. Hence I would be suspect about a VCS that "encourages" or
>> "facilitates" the practice of sequestering work. That is I don't
>> consider non-accessible branching as a qualified value proposition
>> for DCVSs (or more accurately termed replicated VCSs -- but that's
>> just semantics ;-).
>
> We evidently have different styles of formal solving; mine is a
> balance between an internal - or semi-internal - process and an
> "accountable" collaborative effort. I do not see the value of
> everybody seeing every single key stroke I make, as long as they see
> certain sync points; actually, quite analogously to the operational
> semantics of C++ - that certain points at the execution have to
> follow some rules...

Hm.. I must be not understanding something.. Are you arguing that not 
all commits/check-ins you do to a local/private repository are important 
enough to merit the benefits of collaboration? I ask because my 
contention is that if it's important enough for you to put something 
into a VCS history, it's important enough for you collaborators to 
inspect it.. for perpetuity. And that the sooner that inspection happens 
the better it is for everyone. Hence that deleting such history is 
counter to collaboration.

Note, I'm not arguing against DVCSs.. Just against the ones that 
encourage such a practice. Or alternatively, warning that having a 
process that encourages the practice of deleting history is something 
that should be avoided, regardless of VCS.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail