Sorry for not getting you a response sooner. On Thu, Dec 01, 2005 at 04:48:30PM -0800, Howard Spindel wrote: > I have two monotone databases. > > I performed "monotone db migrate" successfully on the first one, and > a key was stored in the new Windows location. > > I then attempted "monotone db migrate" on the second database and got > the following error: > > monotone: error: Cannot store key '[EMAIL PROTECTED]'; a different key > by that name exists. > > Apparently I had different keys in the two databases and that worked > because the key traveled with the database. Now that it's moved to a > fixed location it collides.
Yeah. This was always a problem waiting to happen, unfortunately, as soon as the two keys got mixed up (say if you used the same server to post changes to both projects). One of the good points of the fixed location is that it makes it much harder to accidentally get into this situation in the first place... > What is the recommended procedure to fix this? Unfortunately, there is no great solution to this :-/. About all you can do is throw out one of the keys, and re-issue your existing certs with the key you keep. (The branch certs are the important ones, though you might want to re-issue the other ones too.) And then tell all your friends and your server admin to all throw out your old key, and maybe delete your old (pre-reissue) certs. There's no way to rename a key, or have multiple keys with the same name. Key management in general is quite an annoying problem, and we've been deferring it until now in order to get basic VCS stuff in. I'm sort of amazed people haven't run into such issues more often, actually, but, it's seemed to be very rare in practice, so it hasn't come to the top of the priority list... which, of course, is no excuse. Apologies that we don't have anything better. There are a few different options that might make sense, in an ideal world. The tricky part is essentially a UI question -- how to make sure that people's practices when referring to and reasoning about keys, actually work. In particular, it seems important to be able to tell someone "oh, yeah, I know [EMAIL PROTECTED], you can trust her code", and know that when they go on their computer and say "[EMAIL PROTECTED]", that will end up referring to the same key that _your_ computer has as being labeled "[EMAIL PROTECTED]". There's been some discussion of this before; there are at least two possibilities I know of -- some sort of "referential contagion" scheme, where people you talk to get infected with your name<->object mappings, and some sort of scheme where we have a quasi-centralized per-project trust database people use, and this also holds the name<->object mappings. Both are discussed somewhat here: http://article.gmane.org/gmane.comp.version-control.monotone.devel/5245 Hope this helps, -- Nathaniel -- "The problem...is that sets have a very limited range of activities -- they can't carry pianos, for example, nor drink beer." _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
