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

RE: svn obliterate: The four types of obliteration

From: Andy Bolstridge <andy_at_bolstridge.plus.com>
Date: Tue, 19 May 2009 06:19:58 -0700 (PDT)

I read your 2x2 with interest.. here's my thoughts:

Virtual obliteration is practically never useful, given the 2 dominant reasons for obliterating something (you've checked in a huge file and want to reclaim disk space, or you've checked in some confidential info), you will always want the data to disappear as completely as is reasonably possible.

If the data still resides in the repository, even if it is hidden, you have not solved either problem - someone could use the filesystem to extract the data (tricky but doable) and the space is still taken up.

I would say that absolute obliteration is not as difficult (ha, what do I know!) as it sounds. You do not have to really replace the complete repository, just replace the contents of the revisions on disk (and mark them as obliterated, and/or update the deltas of surrounding revisions).

I would also say that the offline mechanism is also a poor solution. Most people would want the repository to remain online during the obliteration process, and keep revnums intact. An offline obliteration (eg dump/load) is not nearly as good a solution as is required.

I suppose it is possible to work with existing WCs - WCs handle deletion of files correctly today, so the worst case for obliterate is to remove the contents of all revisions, and perform a delete on what's left of the file.

So is it possible to remove file contents while keeping the revision history? Would this be a good solution to the problem, even though it wouldn't completely remove all trace of offending files?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2312967
Received on 2009-05-19 17:37:14 CEST

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