Re: [Monotone-devel] cvssync-refactor

[William Uther]

On 09/03/2007, at 8:03 PM, Nathaniel Smith wrote:

> On Fri, Mar 09, 2007 at 07:20:34PM +1100, William Uther wrote:
> > Because mtn_cvs is now using mtn automate to get at the database, it
> > doesn't seem to have a transaction wrapped about everything any
> > more.  This means that if something goes wrong during an mtn_cvs
> > operation, the mtn database can be left in an inconsistent state.
>
> Please define "inconsistent state"?  It should be possible to get a
> database that contains some stuff that isn't quite as complete as you
> were expecting, but this is usually not that big a deal.  It shouldn't
> be possible to get a database that makes anything blow up.

Well, I was trying to use the cvssync.refactor branch which is...  
adventurous of me.  I'm also using a slightly older version of it  
that I have tested.  It uses a slightly different db layout to 0.33  
which is the version of mtn installed for general use.  This mixture  
of versions (and user error) may have also caused corruption at some  
point.

It was somewhat unclear at times what was causing the corruption  
because there were a few sources:

  i) cvssync and non-clean aborts
  ii) monotone version mismatches accessing a db
  iii) bad keys causing certs that can't be verified with the public  
key in the db
  iv) if you kill_rev_locally on the db with the missing certs then  
you get some orphaned files and manifests that then cause mtn to  
complain

I'm not sure I can separate these neatly though.  I think it is  
easier for the bad keys to be an issue if you're using ssh as the  
transport - it isn't checking the key of the person doing the push.

I've cleaned it up now and the bad db's have gone away so that I  
can't accidentally sync with them.

If I see these problems again, I'll keep a db somewhere for a post- 
mortem.  (I may be able to dig up a broken db from someone else early  
next week, I'll see...)

Cheers,

Will        :-}