Contents of .bzr/merged-patches

[Aaron Bentley]

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

Martin Pool wrote:
| On Wed, 2005-04-20 at 15:38 -0400, Aaron Bentley wrote:
|
|
|>I'd like to propose that, in addition to literally merged patches, the
|>.bzr/merged-patches file should list all patches whose changes are
|>reflected in the tree.
|
|
| So you're saying it should be the transitive closure of merged patches,
| not just the directly merged patches?  Yes, I think that makes sense.

Not only merged patches, but committed patches too.

|
| At the moment I think we shouldn't store that list in every revision,
| because it gets too big, but rather calculate and cache it in the
| working revision.

Okay.  I guess that info's also in the log headers?

|>If this change were done, an un-merging (e.g. bzr merge . at 25 . at 24) would
|>~ remove the merged-patches entry for @25.  This is roughly the model of
|>Arch tree logs.
|
|
| I'm not sure yet that it's a good idea to allow revisions to be taken
| back out once they're gone in.  The model of revisions is simpler (but
| maybe less useful) if they monotonically increase.

Allowing revisions to come out means you can do bzr missing BRANCH.  It
means you can select a merge BASE by finding the first ancestor of OTHER
present in THIS (or vice-versa), and that you can detect cherry-picks.

But there are two possible intents when un-merging.  One is: "This
changes aren't appropriate right now.  I'll undo them, do something
else, and merge them back later."  For this case, it's most helpful if
the merged-patches entries disappear.

The other case is "I think these changes are a bad idea.  I want to get
rid of them and never merge them again."  For this case, it's more
helpful if the merged-patches entries remain.

David Allouche thinks there are actually three possible states for a
revision: missing, merged and rejected.  This may also shed some light.
~ It could be that we want merged-patches AND rejected-patches.

If the changes have been reversed without altering merged-patches, there
are two problems selecting a common ancestor:
1. The last ancestor of OTHER in merged-patches for THIS may not be a
good base, because the changes introduced by that ancestor may not
appear in THIS.  That could cause unnecessary conflicts.

2. When the last revision of OTHER in merged-patches for THIS is found,
we can ensure that it's a good candidate by looking for all of its
ancestors in merged-patches.  If any ancestors are missing, their
changes will also be missing, so the candidate is not a good candidate.
~ Again here, we would miss the fact that a candidate was not a good
candidate if no entries were ever removed from merged-patches.

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

iD8DBQFCZzUh0F+nu1YWqI0RAn9TAJ96Unu7yJgi7sL5qH1a5Auncs6N7ACdGlt2
Cta2nnwJhlMP+9pBmI4XbdI=
=p+/0
-----END PGP SIGNATURE-----