Re: RFC: mtn split (Was: [Monotone-devel] Best practice using monotone)

[Daniel Carosone]

On Thu, Aug 24, 2006 at 01:22:28PM -0500, Chad Walstrom wrote:
> So, if I'm following this correctly and referencing the DaggyFixes
> page, what we have here is something like this:
> 
>                 A--B--C
> 
> Where A is the buggy revision, and B is the revision containing the 5
> bug fixes. 

Where the assumption is you want just one of those fixes separately,
perhaps to also apply it, DaggyStyle, to a release branch?  Ok so far.

> According to Justin's comment, which I think is right on,
> you need to back out the changes in B completely.
> 
>         mtn disapprove B

Um, not what I'd suggest.

What I'd recommend in this case, instead, is to check out another copy
of A, and apply just the fix you wanted from B (without the others).
If this was something that could be separated from the others easily
by filename, you might use pluck to help you get just that fix.

Then you have

          A--B--C
          `-BB

and you can merge BB with C to produce a new head D, probably cleanly.

You can then also proceed to merge BB with whatever other children of
A need just-this-fix, exactly as in the DaggyFixes page.

This is much like the 'daggy release management' examples, where a
specific fix committed somewhere well downstream is first recommitted
in the Daggy location, and then merged forward again.

The 'split' command seems like an interesting idea; if I understand
correctly, it would create lots of parallel BB1, BB2, BB3... revisions
as children of A, in the above example.  The problem I forsee with
this is that it will create a lot of unnecessary fanout (especially if
most of the split-out changes are not the ones you want), and that
it's hard to automatically pick the split boundaries: per file? per
diff 'hunk'? what if there are related changes you want?

An alternate idea would be a kind of 'selective re-apply'; go through
each of the changes in A-B, and for each one either add it or don't,
then commit the result.  Before you imagine what a user interface for
this might look like, consider just taking the diff between the two
and using a text editor to select hunks you want, then apply the
trimmed diff.  That's the basic operation being done, even if you have
some kind of smarter interactive merger helping you along.

It would be handy if we could consume diffs that still paid attention
to our rename/etc 'comments' at the top, here, and also if 'pluck'
could output the adjusted diff rather than just applying it. However,
you could always pluck into a scratch workspace, diff > file, then
revert or apply to another workspace.

--
Dan.

pgpYRDbA8UQRc.pgp
Description: PGP signature