That's a good write-up, but it doesn't handle the other big design
decisions for obliterate: whether it's acceptable for the data to be
reconstructible by somebody with direct access to the repository, and
whether it's acceptable for space to not be reclaimed after
obliterate.
(For FSFS in particular, the answer to these questions hugely
constrains implementation alternatives, since node IDs include the
offset in a rev file.)
--dave
On Thu, Feb 5, 2009 at 8:30 AM, Magnus <account_at_zulutime.net> wrote:
> Thanks for the encouragement, Julian. As a matter of fact, I
> had written up more on the definition, but had intended to hold
> off until after relese 1.6, assuming that things would ease up
> after that. However, I will send what I have prepared now,
> and would welcome any comments.
>
> The following text would belong somewhere early in a revised
> functional specification for obliteration:
>
> -------------------------------------------------
>
> DEFINITION OF THE OBLITERATION OPERATION
>
> An OBLITERATION SET is defined by a list of PATH_at_REVISON elements
> (that is, each element is a pair, consisting of a PATH and REVISION).
> The same PATH can be paired with multiple REVISIONS to form
> multiple elements and vice versa.
>
> Note: The set is restricted so that if, for a given REVISION,
> PATH_at_REVISION is part of the OBLITERATION SET, any element of
> the of the form [PATH/RELATIVEPATH]@REVISION is also part of
> the set. (This simply means that if a directory change is
> obliterated in a revision, all changes to its contents must
> also be obliterated in the same revision).
> [Note on the note. Perhaps this restriction can be lifted.
> However, it seems that doing so would greatly complicate
> both the behavior and implementation of the operation,
> without much benefit.]
>
> An ORIGINAL repository is a repository to which an OBLITERATION
> operation could be applied, but has not (this includes any
> subversion repository without obliterations).
>
> A MODIFIED repository is a repository which is identical to the
> ORIGINAL but for which an OBLITERATION SET has been defined and
> an OBLITERATION operation has been applied.
>
> The OBLITERATION operation is defined by the following two properties:
>
> 1. If a PATH_at_REVISION is checked out of the MODIFIED repository,
> and the PATH_at_REVISION is NOT in the OBLITERATION SET, the
> checkout data is identical to what would have been returned
> if PATH_at_REVISION had been checked out of the ORIGINAL.
>
> 2. If a PATH_at_REVISION is checked out of the MODIFIED repository,
> and the PATH_at_REVISION IS in the OBLITERATION SET, the
> checkout data is identical to what would have been returned
> if PATH_at_REVPRIOR had been checked out of the ORIGINAL, where
> REVPRIOR is the last revision prior to REVISION for which
> PATH_at_REVPRIOR is not in the OBLITERATION SET.
>
> 3. Any other mechanism through which a user can interact with
> the repository (diff/merge/copy/commit/etc) should work
> consistently. That is, assume that a REFERENCE repository
> existed from which nothing had been obliterated, but for
> which any checkout operation yielded the same data as for the
> MODIFIED repository. Then every remote interaction with
> MODIFIED must yield a result indistinguishable from what
> would happen if the same operation were applied to the
> REFERENCE repository.
>
> Note: Here, data refers to the reported existence of the path,
> the versioned properties that apply to the path, and for files,
> the actual contents of the file.
>
> Note: This definition does not state what happens to
> revision properties (several options are available), and it
> does not state what happens to the reported history of
> the path (again, several options are available).
>
> Note: Implicit in the above is the fact that the core
> OBLITERATION functionality would not drop empty revisions.
> This is intentional, and dropping empty revisions should be
> done through a separate mechanism.
>
> -------------------------------------------------
>
> The above definition fulfills several desirable criteria:
> * It is in my view parsimonious
> * It is relatively short
> * It has clearly defined behavioral implications
>
> However, the make-or-break criteria are of course two:
> * Can obliteration, as defined above, be feasibly implemented?
> * Would such an implementation address all required use-cases?
>
> I believe the answer to both of the above questions to be yes,
> and I would be happy to elaborate on why I believe this to
> be the case, through discussions on the mailing list and through
> patches to the functional specification.
>
> Best regards,
> Magnus
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1108134
>
--
glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1109763
Received on 2009-02-06 01:29:49 CET