On 9/27/06, Vlad Skvortsov <vss@73rus.com> wrote:
> 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).
That can be done today (and would be in such a situation), simply
insert empty revisions in place of dropped ones. I believe
svndumpfilter already has support for such a thing. Yep, the default
behavior for svndumpfilter exclude is to leave empty revs, you have to
use --drop-empty-revs to make it leave out a rev even if there are no
changes left in it.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 28 05:29:48 2006