Re: [Monotone-devel] Database gone wild...

[Nathaniel Smith]

On Fri, Mar 09, 2007 at 10:39:07AM +1100, William Uther wrote:
> I'm just about to ditch all the DBs in our cloud and start again.   
> Those revisions signed by a bad key keep coming back to haunt me -  
> someone always syncs with a db that still has them...

Yeah, monotone is really really good at keeping your data safe, but,
umm, need a good trust model to go with that...

> Then there was the problem with cvssync where it was moved to a new  
> server that didn't have a key generated before it was run the first  
> time.  Rather than erroring out, it added two revs without any certs  
> and the scripts then synced them into the cloud.  Wheeee.  A db check  
> now gives:

This is really not a big deal.  You can add certs to those revs if you
want; you can kill_rev_locally them if you want (they probably won't
even be transmitted over netsync, because they have no branch certs,
the exception is if they have children that do have branch certs),
you can ignore them, whatever.  db check is just whining.

> The problem is that I need to stop people from syncing the old broken  
> stuff into the fixed up db.  I suspect I want to do something with  
> epochs.  If I 'mtn db set_epoch' on each branch to a random number,  
> that should solve the problem, right?

Yes, that's how epoch's work -- mtn won't let data flow between
databases with mismatched epochs.

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco