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

Re: the obliterate discussion - why dumpfiltering is no valid workaround

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2007-07-21 23:48:59 CEST

Toby Thain wrote:
>>>> But there are situations where one does want real obliterate: many
>>>> corporations need the ability to remove a document from version
>>>> control completely because they were never supposed to have had it in
>>>> the first place (i.e., legal concerns).
>>> So you'd have to eliminate all backups too...
>> Only if you want to stay out of jail.
> Mark Phippard hints at some other shortcomings of 'obliterate' in his blog,
> http://blogs.open.collab.net/svn/2007/07/second-chances-.html
> For instance, a problematic/offensive/illegal commit could well be
> logged in many places, and the data in question may well exist in many
> working copies. It might be very hard to put the genie back in the
> bottle. (To which inevitably someone will respond, "so you're saying we
> shouldn't even try?")

Once again, it is not a question of whether someone can/should do this.
  That decision will be made on its own merits and by the people
involved. The only issue is whether subversion should provide a
mechanism that would not require the system to be out of service for an
extended period of time while the operation is done. And as long as the
dump/filter/load process is the only possibility, anyone planning to use
subversion should consider the need to do this when deciding how much to
put in any single repository.

   Les Mikesell
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 21 23:48:11 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.