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

Re: Alternatives to 'svn obliterate'?

From: Ben Reser <ben_at_reser.org>
Date: 2004-08-05 23:49:35 CEST

On Thu, Aug 05, 2004 at 02:31:15PM -0700, Justin Erenkrantz wrote:
> As you may know, over on at apache.org, we're starting to have our projects
> migrate to Subversion. However, some committers recently committed some
> code that they did not have the intellectual property rights to. So, we
> need to axe those files entirely (or block anyone from seeing them). (Our
> board is getting nervous that we haven't removed it yet.)
> Of course, this calls for 'svn obliterate' (aka Issue #516):
> <http://subversion.tigris.org/issues/show_bug.cgi?id=516>
> Unfortunately, it's still an open issue. =(
> The committers have since re-added non-infringing versions of the file with
> the same path. So, you do have to go searching the history for the
> offending versions of the file. Our initial thought of using path-based
> blocks with mod_authz_svn won't work (without blocking their new files).
> I'm not even sure we can do a straight svndumpfilter as there are 'good'
> version and 'bad' versions of the same path.
> If at all possible, we'd like to avoid doing an entire dump/load cycle. We
> have well over 35k revisions (our repository is over 2GB). Ideally, we
> would run some type of python script to tweak with the fs directly.

If you deleted the files couldn't you do something evil like replace the
revisions that added them with empty revs?

Ben Reser <ben@reser.org>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 5 23:49:49 2004

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