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