[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: <philipp.marek_at_bmlv.gv.at>
Date: 2006-09-19 12:51:19 CEST

May I try a quick summary of what I heard here, an a few conclusions?

Nik Clayton <nik@ngo.org.uk> wrote:
  I can envisage a solution that involves making regular hot copies of the
  repo (say, every hour), and should a problem occur, revert back to the
  previous hour's backup, and replay all the commits except the offending
  one since then.
That sounds a bit like versioning the repository, which could be an easy task if
done to a fsfs repository with a fsfs repository.
In case of a problem the repository is reverted back to the old revision (update
-rOLD), the backend-repository gets its revision number lowered and the
revisions above deleted.
If later commits would be nice to retain, they should be exported from the
backend-repository before changing HEAD.

As to the technical aspect of "svn obliterate", AFAIK the delta mechanism stores
the blobs needed to construct any version.
What happens if the relevant blobs are simply zeroed-out, so that these parts
contain only NUL-bytes? Of course, then we're back to the problem with
dependant revisions ...

Of course, that all won't help as long as someone has updated on the right time
- the .svn directories will hold the "bad" version for a potentially long time

That brings us to a new aspect: Every "svn obliterate" *must* (IMO) create a new
revision which marks all obliterated files as changed, to get the clients to
fetch a "clean" state. Whether that state is deleted, 0byte length, or
whatever, doesn't matter.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 19 13:03:52 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.