Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > Re: Comment on obliterate functional specification

subversion
Discussion topic

There will be a brief maintenance window every Friday at 17:00 Pacific.
For further details, see CollabNet's maintenance and upgrade policy.

Back to topic list

Re: Comment on obliterate functional specification

Author glasser
Full name David Glasser
Date 2009-02-05 16:29:34 PST
Message 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 dot 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@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@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@REVISION is checked out of the MODIFIED repository,
> and the PATH@REVISION is NOT in the OBLITERATION SET, the
> checkout data is identical to what would have been returned
> if PATH@REVISION had been checked out of the ORIGINAL.
>
> 2. If a PATH@REVISION is checked out of the MODIFIED repository,
> and the PATH@REVISION IS in the OBLITERATION SET, the
> checkout data is identical to what would have been returned
> if PATH@REVPRIOR had been checked out of the ORIGINAL, where
> REVPRIOR is the last revision prior to REVISION for which
> PATH@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.ti​gris.org/ds/viewMess​age.do?dsForumId=462​&dsMessageId=110​8134
>



--
glasser at davidglasser dot net | langtonlabs.org | flickr.com/photos/glasser/

« Previous message in topic | 4 of 20 | Next message in topic »

Messages

Show all messages in topic

Subject
Author
Full name
Date posted
+
Comment on obliterate functional specification Magnus <account at zulutime dot net> Magnus <account at zulutime dot net> 2009-01-20 20:14:34 PST
     Re: Comment on obliterate functional specification julianfoad Julian Foad 2009-02-04 14:59:34 PST
         Re: Comment on obliterate functional specification Magnus <account at zulutime dot net> Magnus <account at zulutime dot net> 2009-02-05 08:30:16 PST
             Re: Comment on obliterate functional specification glasser David Glasser 2009-02-05 16:29:34 PST
                 Re: Comment on obliterate functional specification account at zulutime dot net account at zulutime dot net 2009-02-05 18:08:17 PST
                 Re: Comment on obliterate functional specification Philipp Marek <philipp dot marek at emerion dot com> Philipp Marek <philipp dot marek at emerion dot com> 2009-02-05 22:48:33 PST
             Re: Comment on obliterate functional specification Daniel Shahaf <d dot s at daniel dot shahaf dot name> Daniel Shahaf <d dot s at daniel dot shahaf dot name> 2009-02-20 13:25:16 PST
                 Re: Comment on obliterate functional specification "Magnus dot dot dot " <zulutime dot net at gmail dot com> "Magnus dot dot dot " <zulutime dot net at gmail dot com> 2009-02-21 14:20:26 PST
             Re: Comment on obliterate functional specification jackrepenning Jack Repenning 2009-03-02 19:24:15 PST
                 Re: Comment on obliterate functional specification brane Branko Cibej 2009-03-02 19:46:52 PST
                     Re: Comment on obliterate functional specification Magnus Torfason <zulutime dot net at gmail dot com> Magnus Torfason <zulutime dot net at gmail dot com> 2009-03-03 12:48:11 PST
                 Re: Comment on obliterate functional specification "Hyrum K dot Wright" <hyrum_wright at mail dot utexas dot edu> "Hyrum K dot Wright" <hyrum_wright at mail dot utexas dot edu> 2009-03-02 19:57:15 PST
                     Re: Comment on obliterate functional specification brane Branko Cibej 2009-03-02 20:05:44 PST
                         Re: Comment on obliterate functional specification "Hyrum K dot Wright" <hyrum_wright at mail dot utexas dot edu> "Hyrum K dot Wright" <hyrum_wright at mail dot utexas dot edu> 2009-03-02 20:14:10 PST
                             Re: Comment on obliterate functional specification brane Branko Cibej 2009-03-02 21:09:30 PST
                                 Re: Comment on obliterate functional specification jackrepenning Jack Repenning 2009-03-03 09:40:40 PST
     Re: Comment on obliterate functional specification Magnus Torfason <zulutime dot net at gmail dot com> Magnus Torfason <zulutime dot net at gmail dot com> 2009-03-04 14:50:23 PST
         Re: Comment on obliterate functional specification jackrepenning Jack Repenning 2009-03-04 15:04:47 PST
             Re: Comment on obliterate functional specification Magnus Torfason <zulutime dot net at gmail dot com> Magnus Torfason <zulutime dot net at gmail dot com> 2009-03-05 14:06:03 PST
                 Re: Comment on obliterate functional specification brane Branko Cibej 2009-03-06 11:04:01 PST
Messages per page: