Re: [Monotone-devel] Re: new feature: 'mtn pluck'

[Daniel Carosone]

On Thu, Jul 06, 2006 at 09:27:22PM +0100, Bruce Stephens wrote:
> >> Cool.  Can rev1 be a descendent of rev2?
> >
> > Yes.  rev1 and rev2 can be completely arbitrary (though one may or may
> > not find this freedom useful).
> 
> Right.  The specific case I was thinking of was reverting some change
> in the past (so rev1 and rev2 would be ancestors of the workspace).

In cases like this, where you can identify a specific change (or
series of changes) that introduced a bug/regression, I'm a big fan of
really using the DAG structure for advantage.

If the delta A->B introduced a bug, and there's a series of children
B->..->E that have inherited the bug from B, we have two choices for
how to commit the fix F:

 * as a child of the current head, E->F, possibly using 'pluck' or
   similar tools to apply the reverse diff B->A.  This is what you're
   suggesting, and the only option (so established practice) in
   traditional sequential VCSs.  You might annotate the fix with some
   mention in the changelog of the bad revision being backed out, but
   that's usually as far as it goes.

 * as a direct child of the revision that introduced the problem,
   B->F, and then merge the two heads E and F to produce M.

I strongly prefer the latter: it gives you a strong representation
which you can see easily in a tool like monotone-viz, and propagate
further with the in-built merging tools, of the revisions containing
the bug (all the revisions in the parallel path(s) spanned by
B->F->M).

Lets suppose, furthermore, that you had started a new release branch
from D, midway along the span containing the bug. (The important thing
about a release branch being that you don't intend to merge it back to
mainline, nor to propagate new developments in mainline to it
wholesale). 

You can immediately see that your branch D->R1->R2 contains the bug -
and even better, propagating F to that branch does exactly the right
thing: merges F from the common ancestor B with R2 to produce a fix on
the branch, RF. This is just as well annotated in the graph, without
introducing any of the other changes added in mainline below D, past
the branch. 

Add a new test and testresult cert (and/or some new 'bugfix' cert to
correlate with your BTS) along with the fix in F, and it becomes even
clearer where your fix has propagated if your tool can colour the
graph accordingly.  The basic point is to fix bugs as close as
possible in the revision graph to the point where they were
introduced, rather than the point where they were later found in a
distant descendant.

All of these things you can (and in my humble opinion, should) be
doing with the tool as it stands today .. er .. yesterday. :-) The new
pluck command (and similar cherrypicking style tools) *are* useful,
but for more distant cases and types of usage patterns which can't fit
so directly to a revision graph. 

Perhaps a good example might be the reverse case of what I outlined
above in the first example.  Say a bug had been found and fixed in
mainline at the head, with the fix along the edge E->FF, just checked
in as a normal change.  It might be a nice thing to go back up and
create the 'proper' fix node F as a child of B, to gain the advantages
outlined above. This is easy, now:

 $ mtn co ... -r B
 $ mtn pluck -r E -r FF
 $ mtn commit 

This new F will merge cleanly with FF on mainline, and also alow F to
be merged or propaged with the release branches and other things that
have inherited from B, as previosuly.  This is once again better than
plucking E->FF onto the release branch as a patch R2->RF.

Another example is where you've done a whole pile of development in a
private branch, but for one reason or another you really don't want or
see the need to publish the whole history and internal workings for a
push into a more public repository.
   
And certainly, yes, in some of those cases being able to pluck a
reversed change can be just as useful as a forward one.

I should probably write up a wiki page with some pretty diagrams to
help illustrate this. I think I'll call it DaggyFixes :-)

> I guess it might be nice to have a restrictions version, too, so one
> could apply particular changes to netxx, or something.  Probably not
> that important, come to think of it.

It would be nice, so you could be more specific about which files you
wanted diffs of.  As a first principle for UI design, I would expect
that "mtn pluck <...>" would apply exactly the changes I am shown by
"mtn diff <...>", adjusted for renames etc in the meantime.  If diff
takes restrictions, so should pluck - but if it doesn't I *could*
revert files that had unwanted changed plucked into them.

--
Dan.

pgpGApcX9gCHt.pgp
Description: PGP signature