[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: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-09-18 18:54:16 CEST

On 9/18/06, Brian Behlendorf <brian@collab.net> wrote:

> If this kind of thing happened at Apache while we were using CVS, I think
> we would have responded in the same way as Nik did. If it were to happen
> today, with all of Apache's repositories now under SVN, I think we would
> make the call between either saying "too bad - the company and the
> developer need to figure out the right way to atone for this", or if the
> developer's job really was at risk, taking the repository down for days
> while doing a conversion and then instructing the mirrors to do a clean
> re-mirroring. That's painful but still far less than the pain of sticking
> to CVS would have been. It's also not clear that the story would be any
> different for any other VC system, except those whose repository data
> model looks like CVS's - a model that prevents transactions, versioning of
> directories, efficient tagging, etc etc.

<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>


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 18 18:54:37 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.