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

Re: Issues 516: "svn obliterate"

From: Vlad Skvortsov <vss_at_73rus.com>
Date: 2006-09-28 03:48:59 CEST

Garrett Rooney wrote:

> <svn.apache.org maintainer hat on>
> Actually, it would probably be possible to mitigate the pain somewhat
> by simply turning off access to the portion of the tree in question
> via authz, and then doing a dump/load in the background to get the
> data in question out of the tree. It'd be a pain in the neck, but I
> doubt we'd be stuck taking the whole repos down for the entire
> process. Note that we have had something like this happen in the
> past, and we did turn off access to part of the repos during that
> period of time, although the issue was resolved via some relicensing
> without the need for a dump/load cycle. Brian is right about the
> whole "genie back in the bottle" problem though, it's rather difficult
> to retract data like that once it gets in the open, the only thing
> that would make us jump through the hoops in question is likely a
> potential law suit.
> </svn.apache.org maintainer hat on>

I would like to bring up slightly different topic here, though.
Dump/filter/load cycle can help with getting rid of specific commit, but
another issue here is references. Commit log messages often contain
references to prior commits - in form of "merged r1234:1239 from /a/b/c"
or "follow-up to r1234", etc. It's invaluable piece of information for
any nontrivial project and in my opinion it would be great if the
proposed procedure was able to keep revision numbering intact (just
"blacking out" specific commits).

-- 
Vlad Skvortsov, vss_at_73rus.com, http://vss.73rus.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 28 04:25:20 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.