Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> on Mon, 10 Apr 2006 17:25:56 +0200, Tom > Koelman <[EMAIL PROTECTED]> said: > > tkoelman> Another thing I noticed is that, understandably, all > tkoelman> revision hashes have changed. This has the unfortunate side > tkoelman> effect that propage Changelog entries make no sense anymore, > tkoelman> as they contain two revision hashes from the old database. > tkoelman> Also, some of my handwritten changelog entries have the same > tkoelman> problem. Is there some way in which I can replace these old > tkoelman> revision hashes with their new counterparts? > > You can add a comment if you wish, but that really just pushes it into > the future, if there's another rebuild needed. The revs in the merge > and propagate changelogs are really irrelevant, the ancestors of the > merge/propagate are registered separately, and are always correct. Of > course, that doesn't help your hand written changelogs, but then, in > what situations do you end up writing down a specific revision hash?
Two situations that spring to mind, if I look in our database I can probably find more: - When a series of revisions has to be undone in a follow up revision it is nice to put the revision hash of the revision to which once reverts in the Changelog. E.g.: A -> B -> C -> D D is a revision that undoes the changes in B and C. My Changelog entry would be "Revert to A, because ..." - When code changes get cherry picked and applied to other revisions. E.g.: A -> B -> C D -> E The Changelog entry for E could be "Apply the same changes made in B and C." This reminds me of a related question. Is there any way in which I can find out which new hash maps to which old hash? I ask this, because I wouldn't be surprise to find out we refer to hashes in external documentation as well. Regards, Tom Koelman _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
