[Monotone-devel] Re: Rosterify and certificate keys

[Bruce Stephens]

Bruce Stephens <address@hidden> writes:

[...]

> Hmm.  So one could verify that that worked on a particular database
> (i.e., that the produced selectors selected unique revisions in the
> new database),

For what it's worth, that would seem to work for a copy of the
monotone repository from pre-roster days.  i.e., for every revision,
the selector with branch, author, and date, uniquely identifies a
revision.  As I'd expect.

It doesn't work for the database some of us are using at work.  Many
revisions are produced by Tailor, and some of the dates don't work.
For example, 2006-03-23T14:42:44.972130, and when that gets used in a
selector, no revisions match.  Also, in a few cases two revisions
match have the same date, I think because of a bug in Tailor at the
time (it tracked CVS imports incorrectly).

Anyway, that affects only 45 revisions out of 2416, so I could do
those by hand if necessary.

So I think producing the map from old revision hash to new revision
hash is doable.  And it seems obvious that it would be easy enough to
then produce per-key scripts to create suitable replacement certs, and
similarly, that it would be easy (well, probably) to remove the ones
created by the rosterify process.


When I do our database, I think I'll hack mtn to do it, though.

I imagine mtn knows this mapping while it's converting the database,
so I'd guess it would be straightforward to change it to dump it.

While it's at it, it can dump the revision cert hashes that it's
creating (or directly a script to remove them), and per-key scripts
for creating replacement certs that I can give colleagues.  

Does that make sense?

I guess it's too late for people who have already converted, but would
such a patch be of value to enough people that I should try and write
it cleanly enough that it could be included in the mainline?

[...]