Cherrypicking workflows with bzr

[Martin Pool]

On 18 Jan 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:
> Matthew Palmer wrote:
> > I'm currently using baz to support the following workflow.  Can bzr handle a
> > similar workflow, or how can I achieve a similar result in bzr?
> > 
> > One master trunk holds all of the "common" files for all of the different
> > projects -- templates, common config files, and so on.
> > 
> > There are a number of branches taken from this trunk, one for each separate
> > site we're supporting.  The branch contains customisation of the common
> > config, deployments of the templates into new files, and often new general
> > purpose features needed by a particular branch.
> > 
> > Periodically, we go through the branches and "remerge" all of the useful
> > general features back into the trunk for other branches to use.  Since a lot
> > of changesets aren't suitable for the trunk, we replay the relevant branch
> > changesets into the trunk and then sync-tree all of the unwanted changesets,
> > so that we can use "baz missing" to tell us about what changesets in a
> > branch haven't been merged/ignored in the trunk.
> > 
> > For various practical reasons, we can't always implement new features in the
> > trunk and then push them out to the branch, and it would be problematic to
> > require each new feature on a branch.
> > 
> > I'll happily admit that I'm not "up" on the latest of bzr, and I'm not 100%
> > confident I've got the whole bzr mental model of data and metadata yet, so
> > this may be something that is trivial.  But my current understanding is that
> > bzr's underlying concepts are quite different to baz's, so taking single
> > changesets out of branches and keeping everything straight isn't done in the
> > same way.
> > 
> > All help and comments appreciated.

What would work best with bzr at the moment is to in fact keep things
separate: as with paint it's easier to combine changes when you need
them combined than try to separate them later.  However sometimes it's
either not practical or you only realize after the fact what's needed,
so we will work on better cherrypicking.

> Short answer: Probably not with the current bzr. But maybe after we
> support cherry picking better.
> 
> Long answer:
> I don't think the interface right now lets you do this easily. If only
> because we have no 'sync' command.

By way of background for other readers, Arch's "sync-tree" means "record
in branch X that I merged all the changes from branch Y, but don't
actually merge the text."  (I certainly found this a surprising meaning
for 'sync-tree'.)  It is sometimes used when the merge has been done
other than through the regular merge command.  More commonly, it is used
(as above) to show that the changes from branch Y have been considered
for inclusion in X but not actually included.  This can mean they were
rejected or aren't relevant, etc.

> After thinking about it in long form (se
> 
> But lets try to think about the internal model...
> 
> Lets define some branches
> T - Trunk
> A - Site A
> B - Site B
> 
> Originally both A and B are branched from T.
> In A, you do some work, generating 3 revisions (10, 11, 12).
> Then you do:
> 
> $ cd $T
> $ bzr merge -r 10..12 $A
> This says merge the changes of 12 relative to 10, which should be 11 and 12.
> 
> At this point if you set the .bzr/pending-merges to include
> revision 12, to $T it will look like you merged everything in
> $A
> $ bzr sync $A # Theoretical command
> 
> You should get equivalent results by doing:
> $ bzr merge $A
> $ bzr merge --force -r 10..9 $A
> 
> Which is basically saying, merge all of A, and then remove the changes
> for revision 10. (--force is necessary because merge doesn't like to
> merge into a modified tree)
> 
> At this point you
> $ bzr commit -m "cherry pick A-11,12"
> 
> Now, the ancestry should look like:
> 
> T1 --- T9 ---------------.-> T10
>         |               /
>         v              /
>         A10 -> A11 -> A12
> 
> At this point if you
> $ cd $A
> $ bzr merge $T
> 
> What you want is for it to not do anything. However, I think the merge
> code would pick A12 as the common ancestor for both trees, and then
> notice that T10 changed some stuff.
> Base = A12, This = A12, Other = T10
> That would show a content change, which would be applied A (effectively
> reverting A10).
> 
> However, if you go to A and 'sync' T the ancestry looks like:
> 
> T1 --- T9 ---------------.-> T10
>         |               /     \
>         v              /       \
>         A10 -> A11 -> A12-------`-> A13
> 
> 
> At this point, if you were in A and you did:
> $ cd $A; bzr merge $T
> Then it should pick T10 as the common base.
> Base = T10, This = A13, Other = T10
> 
> Which has no changes to merge.
> 
> However, going back to $T
> $ cd $T; bzr merge $A
> It would pick
> Base = T10, This = T10, Other = A13
> Which would have changes to merge.

Matt doesn't actually say he then re-merges the trunk into those site
branches.  Perhaps it would be an obvious thing to do, but perhaps not.

> So I think are diff3 merging would not do what you would want. Because
> we look at the specific contents of BASE, THIS, and OTHER, and merge
> from there. If BASE & OTHER are not identical, it will try and merge
> those changes.
> 
> Now what about Weave merge? Going back to the first scenario, where T
> has cherrypicked A's changes. Revision T10 specifically deletes the
> lines from A10, so A10 would try to delete them => failure.
> 
> And if we 'sync' A versus T10, it actually looks like the lines are
> specifically created by A13 (resurrecting deleted lines looks like a new
> addition, they do not keep the old revision identifiers one of the
> limitations of our weave format). So again we fail.
> 
> So it doesn't really seem possible.

I'm not sure, but I think Baz or Arch will get into the same situation
if you cherry-pick, sync-tree and then star-merge.  You can get away
with it if you keep on using replay or update.

-- 
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/20060119/cf1e689b/attachment.pgp