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.
Regards,
Phil
---------------------------------------------------------------------
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