[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: Magnus <account_at_zulutime.net>
Date: Thu, 5 Feb 2009 08:30:16 -0800 (PST)

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
Received on 2009-02-05 18:57:31 CET

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