[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PROPOSAL] how to implement 'svn obliterate'

From: Blair Zajac <blair_at_orcaware.com>
Date: Wed, 16 Apr 2008 14:05:49 -0700

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

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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.