Cherrypicking workflows with bzr

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
| 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.

For three-way merges, there's probably no harm in including the changes
made when merging from B.  That's like tla update --three-way (which
never existed, but I did in Fai).  And with weave merges, adding an
already-present change is a no-op.

| 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?)

I have used it.  It's better than nothing.  But I believe doing update,
rather than skip-present addresses these problems.

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

Based on my experience with diverged trees in Arch, I would say that we
do not want rejections to propagate by default, so that the patch
originator loses their changes.

Perhaps the rule would be:
1. if the patch has been applied, do not accept a rejection for it.
2. otherwise, accept rejections.

| 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 would like to keep as much information as possible at a higher level.
~ I'm not sure whether that makes sense for exclusions and cherry-picks,
but it might.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD1GDO0F+nu1YWqI0RAs5mAJ4jS0Ye/+2hwo/VqOsSso5+XV5n9wCfVNYt
3J4Ry5YrYinBC7t/XZQnJLQ=
=IRuA
-----END PGP SIGNATURE-----