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

[Ethan Blanton]

Daniel Carosone spake unto us the following wisdom:
> 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?

Those who are familiar with darcs will note that it actually allows
something like this on each commit; you can cause it to present each
diff hunk between the current workspace and the repository one at a
time, and you can either include or reject each hunk in turn.

I find that I very much like the idea of 'monotone split' (after all,
who hasn't accidentally commited an unrelated change along with a
coherent changeset at one time or another?), but I'm not sure what I
would expect monotone to do for me in this case.  The following is the
best I can come up with, work-flow-wise, but providing a coherent and
usable UI for it which is comprehensible to most would be difficult.

Suppose we have:

A--B--C

Where B is a revision which contains three logically independent
changes from A in one commit.  It would be nice to type 'mtn split -r
B', and have each hunk in B presented, in order, to be applied or not.
Upon approving only those hunks which contain pieces of logical change
#1, monotone allows me to make hand-changes with my editor (for
example, suppose logical change #1 and logical change #1 happen to
change lines very close to one another, putting them in the same hunk,
so some small bit of #2 must be removed).  When I'm happy, I 'mtn
commit', resulting in this graph:

A---B---C
 `-B1

I then type some 'mtn split' incantation (this is the "hard" part to
get right, as far as UI goes, I think) which provides me each hunk in,
this time, the diff between B and B1.  Proceed as before, yielding a
B2 containing all of logical change #2:

A---B---C
|`-B1
`--B2

Rinse and repeat, yielding a B3:

A---B---C
|`-B1
`--B2
 `-B3

At this point, B1 ∪ B2 ∪ B3 *should* look something like, if not
identical to, B.  I should then be able to perform some related
command which yields a graph functionally identical to:

 ,----B---C
|      \
A--B1-----D
|`-B2--'
 `-B3-'

Where C is either B or B1 ∪ B2 ∪ B3 (if they differ).  (I realize that
monotone has no multi-revision-merge, and perhaps should not for some
very good reason have one, so the graph may in reality be somewhat
more complicated than this.) At this point, B1, B2, and B3 are both
free to be plucked or propagated to other branches _and_ clearly
represent what B "should have been" with respect to D.  (The
preexisting C can then be normally merged with D, or whatever, to
continue any development which may have already proceeded from B.)

Now, the hard part here is providing a UI for this which doesn't
require the user to carry around a lot of baggage; for two or three
logical changes it's not hard, necessarily (something like 'mtn split
-r B', 'mtn split -r B --whatever B1', 'mtn split -r B --whatever B1
--whatever B2', etc.), but for large such revisions it gets ugly fast
if the user has to track each sub-changeset revision individually.
Perhaps the best interface is really something like pluck-and-prune
followed by merge (maybe with a tool to approve individual "hunks" of
the plucked diff one by one, as Daniel recommended) with no such logic
for "ignoring" sub-changes as I describe above, but this seems like
the most logical place where monotone can "help" to me.

Hopefully that was halfway coherent.  ;-)

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

signature.asc
Description: Digital signature