Contents of .bzr/merged-patches
aaron.bentley at utoronto.ca
Thu Apr 21 06:07:45 BST 2005
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar