[Monotone-devel] Re: Rosterify and certificate keys

[Tom Koelman]

Richard Levitte - VMS Whacker <address@hidden> writes:

> In message <address@hidden> on Mon, 10 Apr 2006 17:25:56 +0200, Tom Koelman 
> <address@hidden> 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