Cherrypicking workflows with bzr

[Martin Pool]

On 19 Jan 2006, John A Meinel <john at arbash-meinel.com> wrote:
> I'm guessing he wouldn't right away, but he probably would after he
> merged someone else's changes. And wouldn't want previous changes to
> disappear.

I think the big issue here is not so much cherrypicking, as 'rejected
patches'.  (See e.g. ddaa's post
http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/702)

(Certainly we could make our cherrypicking support, and particularly
tracking of that, a bit better and that would help too.)

Repeated merges from A to B and B to A "try" to make the two branches
converge to the same state.  Any new information in A, including
reversion of changes in B, gets pulled across into B when you merge in
A.  (And maybe it wouldn't really matter how that information is
represented, whether as a series of patches, or weaves with new lines
getting turned on, etc.)

This is generally what you want, at least as a reasonable default for a
merge command.  But sometimes the two branches want to "agree to
disagree" about what should be there.

sync-tree doesn't really help with this because it's equivalent to
merging and discarding the text changes.

Here are a few possibilities:

One possibility is that the user must then keep on cherrypicking
manually in future: bring the newly-integrated features in from the main
branch, but not the parts that conflict with what was originally done.

We could perhaps add something like "baz replay --skip-present".  If
this were used in merging from A to B, it would bring across all the new
changes in A except for those made when merging from B.  In particular
if A had done a merge-and-discard from B, skip-present would avoid
causing the changes to be discarded in B.  It should be reasonably easy
to determine the changes in A that merge changes already present in B.
But skip-present seems to me like a bit of a blunt tool: you lose A's
resolutions of regular merges from B, and possibly also lose large
merges from somewhere else that just happen to have one revision that's
already in B.  (Does anyone use it/like it in Arch?)

Another might be to record a separate list of "rejected patches" within
a branch: these have not been merged, but are not considered for merging
in the future either.  The big question is how this should propagate
between branches: when B merges from A we presumably wouldn't want this
to reject patches originally created in B.  Or would we?  Perhaps this
should propagate through pulls, but not merges.  Or perhaps it should 

Another approach is to handle rejected and cherry-picked changes at the
weave level.  SCCS has something like this; I'd previously avoided it
because it seems to cause them considerable complexity but it's probably
time to add it.

You can think of the weave as a tightly compressed list of deltas that
should be applied to extract a particular version of a file.  At the
moment the deltas to apply are all of those used by the parents, plus
that of the revision itself.

Suppose we don't just use the total of these, but also allow for
revisions to be individually added or removed.  So if we have a weave
like this (where version 1 has two lines)

version 0 = 0
version 1 = 0 + 1
add 0 {
new in line
}
add 1 {
new in version 1
}

we can make a new revision 2 which descends from 1 but undoes the
changes in 0 by just recording that in the index.

Similarly if we want to pick in just one changeset, or selected
changesets, from another branch, we can do that.

One complexity comes when we have a revision with two parents, neither a
parent of the other, where one of which specifically enables 0, and the
other specifically disables it.  We need to decide what to display in
the merged text, and whether a conflict indicator will be displayed
there.  Perhaps this should be reported as a special type of conflict.  

When we record the new merge revision we need to make sure it
unambiguously records what was chosen; perhaps the header should simply
state all of the individually enabled or disabled revisions.

This does mean that evaluating the list of active inclusions is more
complex, and possibly somewhat slower, but probably still quite
feasible.

I'll prototype this when I get a moment.

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060123/e1d904d6/attachment.pgp