Magnus wrote on Thu, 5 Feb 2009 at 08:30 -0800:
> 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:
>
Have we archived this somewhere? On issue #516, or in the notes/
directory, etc.?
Daniel
> -------------------------------------------------
>
> 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
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1200601
Received on 2009-02-20 22:43:18 CET