monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] repository surgery


From: Daniel Carosone
Subject: Re: [Monotone-devel] repository surgery
Date: Fri, 2 Oct 2009 13:04:21 +1000
User-agent: Mutt/1.5.19 (2009-01-05)

On Thu, Oct 01, 2009 at 10:29:02PM -0400, address@hidden wrote:
> But -- saving grace -- I have physical control over all the copies of 
> the repository.

I presume you mean all repositories containing copies of the
problematic revs?  In that case, it's just an exercise in preventing
their further escape.

> It this likely to work as a way to clean up the mess? Or is there a 
> simpler way?
> 
> (1) Pull the data base to make a local copy.

You could pull the public repo, as a way of getting a db without your
mistaken changes, too.  This mmight also be missing other private
changes you want, I dunno.

> (2) Use the cammand that removes the most recent change set until I'm at 
> the pount before I added the wrong files.  (I'm presuming that the only 
> reason this is said to not work is that a sync will just bring them all 
> back.  Is this so?  Or is some kind of check performed to prevent it?).

That's primarily it.  There are some other minor wrinkles to do with
additional file content in the db which may become unreferenced (only
the revs are removed).  These can be cleaned up with another local
sync to a new db, but since you're effectively going to do that
anyway, perapsyou can avoid the deleting step, and just be selective
in that sync instead. 

> (2) use the beginning of the branch renaming script to add a branch cert 
> for the correct branch name to every remaining revision.

You can do this part any time (it's just an 'mtn approve' on a set of
revs) without other machinations.  Destroy_revs_locally'ing (ugh :-)
the undesired revs is just a complicated way of making up a selection
set for the remaing revs you want to approve.

It might also be a way to avoid accidentally sending the suspect rvs,
in later syncs.

Anyway, if you can find another way to select the revs you want (like,
perhaps, the ones that come from the public repo in a fresh sync),
just approve those.

> (3) sync with the remote repository (thereby giving me tne entire old 
> branch and the truncated new branch)

I'm not sure I understand your comment here.  Sync would, at this
point, push your branch certs out for the new branch, plus maybe pull
down new public revs.

Again, you could do this without destroy_revs_locally, by just pushing
the new branch name.

> (4) cherry-pick the changes I *do* want into the new branch.

Ok, using workspace operations on the files, outside of mtn, so you
don't make any ancestry links with the bad revs. Then sync/push again,
obviously. 

> (5) If I really want to get rid of the old misnamed branch, pull just 
> the new branch from the local repository to make a new, smaller local 
> repository.  Then destroy all the other repositories so the corrupt data 
> will not sync back in.

Yah.  You can also look at some of the deny hooks to prevent the old
branch name re-appearing.

Good luck.

--
Dan.

Attachment: pgpAMS20O6iCr.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]