[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: Max Bowsher <maxb_at_ukf.net>
Date: 2004-08-05 23:50:22 CEST

Justin Erenkrantz wrote:
> Hi gang!
> As you may know, over on at apache.org, we're starting to have our
> 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
> 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.
> 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

BDB repos, I assume?

AFAIK, the only way to acheive this would be to make edits directly at the
BDB layer, entirely circumventing all subversion libraries.

It's certainly doable. I don't have a script already written, though.

I could have a go at writing one this weekend, if that's any good?


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:50:48 2004

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