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

Re: Comment on obliterate functional specification

From: <account_at_zulutime.net>
Date: Thu, 5 Feb 2009 18:08:17 -0800 (PST)

Agreed, as I mentioned this is intended "somewhere early in a
revised functional specification", it is not supposed to be the
complete specification.

The two issues you mention do indeed need to be agreed on.
However, I would like to note here that in my opinion:

1. Given a MODIFIED repository, property 3 of the definition
   quaranties that space can be reclaimed and data completely
   removed from the repository through a svnsync->replace cycle.
   (Since svnsync must by definition see the repository as
   it would have been had the obliterated revisions never
   been committed).

2. The sync->replace cycle approach to obliteration was
   originally suggested by Karl Fogel (although I believe
   he envisioned the obliteration logic as residing in the
   sync-type program itself, rather than using svnsync as-is).

   For an utter and complete removal from the repository, I
   believe that such a sync->replace cycle (perhaps made
   transparent by encapsulating it in a single operation)
   is the best that can be achieved without vastly
   complicating the operation. The reason:
     If the repository is traversed from revision 0 up to HEAD, it
     is close to impossible to know if a (much) later revision
     includes paths copied from the obliterated sets (in which
     case the data would be lost). Thus, the operation would first
     need to compile a list of every single copy operation, check
     every obliteration against this list, and store the data
     somewhere before removing it from the repository.
     If the repository is traversed from revision HEAD down to 0,
     it will, upon encountering an obliterated modification at
     revision N, merge that modification with whatever happened
     at revision N+1. If it then encounters a modification of the
     same path at revision N-1, it will have to go back to
     N+1 to merge the N-1 mod with the joint N and N+1 mod. This
     means that in doing the obliteration, a revision can not
     be finalized until the obliteration is over. Furthermore,
     whenever a copy is encountered, logic must be applied to
     figure out where it should originate AFTER obliterations
     are performed, and it rewritten. (This might require it to
     be rewritten in a way that is not consistent with the
     earlier revision as it is occurs BEFORE modification)
     Thus to sum up: Any "true" obliteration mechanism
     that does not have access to the complete data of the
     original repository during the whole obliteration operation
     will become hopelessly nonlinear in any scenario, and close
     to impossible to implement on a live repository. My functional
     specification will therefore not require such an approach.

Received on 2009-02-06 11:15:23 CET

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