Karl Fogel wrote:
> This isn't 1.5-related, but I wanted to post it before I forgot.
>
> Here's a cheap plan for implementing 'svn obliterate'. I'm interested
> in implementing it, but there are more pressing things on my plate right
> now, and there's no reason it has to be me. If someone wants to run
> with this, go for it! I will link to this mail from issue #516.
>
> The Plan:
> =========
>
> Use svn_repos_replay2() to send changes through an "obliterate editor"
> (defined below) to create a new repository that doesn't have whatever is
> being obliterated. As necessary, run repeated "catch up" passes until
> HEAD is the same in both repositories. Then lock the old repository and
> replace its db/ subdir with the one from the new repository. Finally,
> remove the remainder of the old repository.
Before I read the proposal, I was thinking you would want to run obliterate
which would create a new repository that one would examine before making the new
repository the master, so the original would not be modified.
Also, how would it deal with commits happening using nodes that are being
obliterated?
With this scheme, I would probably make a copy of the live repository, then run
obliterate on it, examine it, then move it in place of the original repository.
Also, it seems changing the UUID of the new repository would be a good idea to
force clients to do a new checkout.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-16 23:06:13 CEST