Re: [Monotone-devel] problem upgrading to 0.24

[Howard Spindel]

> 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 'address@hidden'; 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.

I tried an experiment to get around this problem.

After performing "db migrate" on db1, I moved the generated key out 
of the Application Data\monotone\keys directory.  Then I performed a 
"db migrate" on db2.

The second "db migrate" worked okay because it didn't see the colliding key.

As far as I can tell, I can still see all of the certificates in db1 
even though they were generated using a key that no longer 
exists.  So far so good.

Then I tried a check-in on both databases.  The check-in on db2 
worked fine as expected.  The check-in on db1 gave me warnings that 
said "ignoring bad signature", but the check-in seemed to work.

So to clear up the warning, I tried "monotone dropkey 
address@hidden" on db1.  Somewhat unexpectedly, that removed the key 
file from Application Data/monotone/keys.  Fortunately, I had thought 
ahead and made a copy of the key file, which I restored to the 
directory, and then did "monotone read".

Now things mostly work okay.  db2 is fine.  db1 gives me some 
warnings about bad signatures on previously checked-in files, but 
checks in new changes without complaint.

So, monotone gurus, did I break anything with this procedure?  I 
suppose the warnings on db1 are bearable if this is the best I can achieve.

I still think (per my other emails) that allowing keys to be database 
specific is desirable, and certainly would address the backwards 
compatibility issue with 0.23.  I have fully backed-up copies of my 
0.23 databases, so if a better solution than my hack above is 
available I can go back to 0.23 and perform the "db migrate" again.

Thanks very much,
Howard