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

Alternatives to 'svn obliterate'?

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2004-08-05 23:31:15 CEST

Hi gang!

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.

Any ideas? Thanks! Beer to those who help. ;-) -- justin

---------------------------------------------------------------------
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:31:30 2004

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.