Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Topher Cooper (topher_at_[hidden])
Date: 2012-03-22 11:50:02

On 3/22/2012 3:57 AM, Thomas Heller wrote:
> No, I am saying that altering history is dangerous! Which you 
> described as one
> of the advantages of "the git approach".

Altering *code* is dangerous.  The issue is to aim at wise judgment in 
regards to cost vs benefit in choosing to make changes either to code or 
to history (or documentation, or specification, or policies, or ...).

Extraneous detail in change history detracts from its usefulness.  If I 
set a backup point in my local history so I can easily back out of a 
small experiment if it fails, it may be very unlikely that this 
"snapshot" (and this would be as a snapshot -- not a unit of work) would 
subsequently be of interest if the experiment succeeds (if it fails, it 
is somewhat more likely that the history may be worth keeping since it 
provides a record that the experiment was attempted, that it failed and 
why it did so; however, a simple log entry -- an underutilized tool 
since the advent of sophisticated VCSes -- might do as well, and the 
experiment might be of such limited scope that this might not be of any 
interest either).  Extra detail obscures important detail, making it 
more difficult to find what is relevant in the history.

I think that one of the most important areas where improvement could be 
made in VCSes (at least in any that I know) is in better understanding 
the contextual and hierarchical nature of history.  Recent history 
should be much finer grained than older history.  What is of importance 
to an individual developer during the coding of a "micro-task", is 
frequently of no interest to a group, and most of the history within a 
"sprint" (to use a term from agile methodology -- a unit of work 
requiring between one to three weeks to perform whether that is 
performed by the group or by an individual within the group) is 
irrelevant afterwards.  Branching, tagging and local sandboxes are the 
traditional tools for this.  The DVCS approach adds local repositories.  
This is certainly a step in the right direction as I see it.

Can a non distributed VCS be used to effectively create a DVCS?  Of 
course, that has been done pretty much since the inception of 
centralized VCS systems, just as individual code management systems were 
used as centralized VCSes from their inception.  A tool designed with 
that use in mind, however, has the potential to perform the necessary 
functions, more smoothly, conveniently, and accurately than something 
cobbled together by conventions and ad hoc scripting.  The question is 
whether particular tools have succeeded in doing this without 
sacrificing other important functionality.  My limited experience with 
git (I have none with Mercurial) leads me to believe that it has.

The statement has been made that (paraphrasing) "any change worth 
committing is worth preserving".  This sees version history as a blunt 
instrument.  Note the immediate and arguably harmful corollary (perhaps 
not even a corollary but simply a rephrasing): "only changes worth 
preserving (indefinitely) are worth committing".  Personally, I try to 
locally commit (with whatever tool I have for such things, including 
simple directory copies) every few control-s'es (where few is a term 
relative to context).  This provides me an opportunity for backtracking 
and to review recent changes.  The chances that any but the last few of 
these routine backups of this kind (again there is a hierarchical or 
even fractal structure here, but lets keep it simple) are going to be of 
use to me are small, and the chances that they will be comprehensible as 
meaningful steps to anyone else without detailed study is virtually 
nil.  That history rapidly becomes not only useless but harmful, since 
it obscures useful information.

The statement was made in response to a challenge as to whether the 
claimant (I think it was Heller, but I'm not sure) recommended 
preserving a record of every save from the editor or every keystroke 
made during editing.  It is a valid question which was answered based on 
the bald assumption that interaction with a VCS represents a fundamental 
difference in kind from other activities -- an assumption that I believe 
to be completely false.  The VCS is a tool whose implementation 
*creates* a totally artificial boundary for workflow.  There is only a 
difference in mechanism, domain/specialization and degree, not of nature 
between DCS commits, branches, tags, editor saves, commenting out code, 
todo comments, temporary flags, code comments about motivation and even 
temporary monitoring and logging insertions and debugger breakpoints.

A VCS version serves a purpose (one or more of a finite list of possible 
purposes).  What is of use to one developer may not be of any use to 
others.  What serves a critical function now may become useless at some 
time in the future.  A belief that all and any detail conventionally and 
conveniently captured by an SVN like system is precisely and immutably 
the correct level of detail to capture seems to me unlikely to be 
correct an a poor assumption on which to base decisions.  (The same is 
absolutely true about git-like tools -- the issue is whether it tends to 
steer choices closer to the ideal and/or make informed judgements easier 
to carry out.  The arguments of the anti-DVCSers on this list are 
leading me to believe that this is so where previously I thought it only 
an interesting claim whose truth I was neutral on).

Topher