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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1110077
Received on 2009-02-06 11:15:23 CET