Cherrypicking workflows with bzr

[Jan Hudec]

On Mon, Jan 23, 2006 at 09:55:19 +1100, Martin Pool wrote:
> On 19 Jan 2006, John A Meinel <john at arbash-meinel.com> wrote:
> 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.

I believe it's the only way to actually handle cherry-picking. The
picked ancestors need to be recorded in the weave index just as
ancestors are recorded there (though both are/can be recorded in the
revision description as well).

> 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.

I think it sounds reasonable this way.

I would add another complex case:

It might happen that a foo branch has a revision, let's call it quux,
that a bar branch needs to pick. However there is a hunk in it that is
related to foo-specific changes, so the revision in bar that picks quux
(let's call it quuxbar) reverts that hunk. Now when foo later merges
bar, that hunk should NOT be reverted.

That would mean that instead of recording that quuxbar includes quux
(without ancestry) and removes that hunk again, to record that quuxbar
includes particular hunks from quux.

> 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.  

With the above it could be a normal conflict. The weaver would have to
be smart enough to recognize whether the hunks come from either ancestry
or are new.

> 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

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- 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/60142458/attachment.pgp