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

svn obliterate: The four types of obliteration

From: Magnus Torfason <zulutime.net_at_gmail.com>
Date: Thu, 26 Feb 2009 12:44:20 -0500

I have some more text that is on its way into the obliteration
functional specification, but I believe this is valuable for anyone who
would like to have an opinion on this design. So I am posting it to the
list as plain text before posting it in patch form. Comments welcome.

------------------------------------------------

A TWO-BY-TWO CLASSIFICATION OF OBLITERATION TYPES

     At a high level, obliteration can be classified along two
     dimensions. The ABSOLUTE vs. VIRTUAL distinction refers to whether
     obliterated data is removed from disk or merely hidden. The
     OFFLINE vs. ONLINE distinction refers to whether working copies
     can continue to be used after an obliteration operation. The
     dimensions are independent, so "ABSOLUTE ONLINE", "ABSOLUTE
     OFFLINE", "VIRTUAL ONLINE" and "VIRTUAL OFFLINE" are all possible
     (although "VIRTUAL OFFLINE" has little use).

   ABSOLUTE

     For an ABSOLUTE obliteration, the repository must be traversed,
     and all obliterated data expunged totally, recapturing disk space
     and preventing a person with access to the repository from
     retrieving the information.

     ABSOLUTE obliteration is very time-consuming and require a
     complete copy of the repository (in all currently proposed
     implementation methods). However, after a (modified) copy is
     created, it can replace the original relatively quickly.

   VIRTUAL

     For a VIRTUAL obliteration, it is enough to mark the obliteratied
     revisions. The server layer will then dynamically determine what
     to return over the RA layer, presenting only the modified version
     to the client.

     Given a repository with VIRTUAL obliterations, ABSOLUTE
     obliteration can be obtained through a svnsync of the repository
     (since svnsync sees the repository only through the RA layer).
     Thus, the obliteration logic would only need to be implemented
     once.

   OFFLINE

     An OFFLINE operation renders all existing working copies invalid.
     The old repository location may or may not be a valid repository,
     but a complete checkout is in all cases necessary to work with the
     post-obliteration version.

   ONLINE

     An ONLINE implementation of obliteration leaves a working
     repository intact at the same location as before, and any working
     copies that are not directly impacted (because nothing from the
     obliteration set has been checked out) can continue to be used. If
     a working copy contains obliterated data, it must be
     updated/repaired/re-checked-out before further work. Furthermore,
     any operations on such a working copy should fail relatively
     gracefully.

------------------------------------------------

Best regards,
Magnus

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1234016
Received on 2009-02-26 19:00:12 CET

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.