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

Issues 516: "svn obliterate"

From: Nik Clayton <nik_at_ngo.org.uk>
Date: 2006-09-17 17:40:06 CEST

Hi,

Is anyone actively working on implementing an API to completely remove a
file from a repository, as described in:

     http://subversion.tigris.org/issues/show_bug.cgi?id=516

?

I'm looking at what would be involved in migrating FreeBSD from CVS to
Subversion, and we think we need this functionality.

As well as the traditional "Someone's committed a core file by accident"
use case that's covered in that issue, we have another use case that
doesn't seem to have been discussed (at least, a quick search didn't
turn it up).

This is where a committer inadvertently commits code that they are not
licensed to commit. This might be a binary blob from a third party
vendor that's not supposed to be distributed, or it might be, as has
happened to FreeBSD, been code being developed for a commercial third
party, that will eventually be open sourced, but that is not supposed to
be open sourced yet.

That's happened to FreeBSD. Some emergency CVS repo surgery meant that
the offending code was removed from the master repo, and all the mirrors
shortly caught up.

I don't (yet) have a solution that will work with Subversion. I'm aware
that it's possible to dump the repo from just before and just after the
commit, load the first dump, manufacture a dummy commit, and then load
the second dump.

However, I don't yet know how feasible that is. First, the dump/load
cycle for a large repository is lengthy -- doing this to a hypothetical
FreeBSD SVN repo, which will contain 10+ years of imported CVS history
is likely to be prohibitively so. Second, I haven't tested what the
effects of this procedure would be on any one who has mirrored the repo
(using svnsync) or has a working copy that contains the offending item.

Alternative approaches, such as restore from a backup prior to the
commit, and replay the remaining commits are also possible, but again,
I've yet to investigate what sort of effect this would have on mirrors
that are svnsync(1)'ing the repo.

Hence our interest in supported command/API that does this.

N

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 17 17:40:25 2006

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.