Bruce Stephens <[EMAIL PROTECTED]> 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? [...] _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
