I have been going through the discussion of the obliterate feature, which,
although it has tended to start and stop, has now found a home in the
functional spec.
(trunk/notes/obliterate/obliterate-functional-spec.txt)
The design of this behavior is not trivial, but although I believe that
the svnsync approach suggested by Karl Fogel (and others, off-list, if I
understand correctly) result in a much more feasible design, I do not
completely agree with his comments (on dev) that there are many possible
ways in which it could behave. More specifically, I believe that different
obliteration use cases all need to be built around a core obliteration
functionality, and that there really is only one good option for
implementing that core in a way which does not lead into a
quagmire of ill-defined outcomes.
Using the language of the specification, (along with a new concept,
that of an OBLITERATION SET) this core consists of:
1: SELECT multiple modifications. These modifications comprise the
OBLITERATION SET in the form of multiple PATH_at_REV pairs.
2: OBLITERATE selected modifications.
Short and sweet :-)
Three observations result from this way of viewing the matter, the first
of which is crucial in my view, the others are "convenience observations"
A: The data of a PATH_at_REV that does NOT intersect with the OBLITERATION SET
is UNCHANGED by an obliteration. Always. History data may change when an
ancestor of the PATH_at_REV has been obliterated, but:
svn co REPO\PATH_at_REV LOCALPATH
results in EXACTLY the same working copy when REPO is the
post-obliterate repository as when it is the original repository.
B: There is no "obliteration of files" that is independent of the
obliteration of modifications. To "obliterate a file" (or directory),
one simply has to obliterate every single modification to that file.
Thus, if a file needs to be completely obliterated, this can be done
by specifying a PATH_at_REV, finding all ancestors, direct descendants
(and optionally copied descendants), and including each of them
in the OBLITERATION SET.
C: There is no "obliteration of revisions" that is independent of the
obliteration of modifications. To "obliterate a revision", one simply
has to obliterate the modifications in the OBLITERATION SET implied by
"/@REV".
If point A is agreed on, I believe that the functional specification could
be simplified quite a bit, with a main section on how to implement
functionality consistent with A, and additional sections on how to
implement specific use cases through the construction of the
OBLITERATION SET in different ways.
I would appreciate any comments on this, and if others concur with this
view, I might contribute a patch to the functional-spec with some edits
reflecting this approach.
Best,
Magnus
ps. I posted this earlier today but it seems to have disappeared. I'm terribly sorry if I am double-posting.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1040326
Received on 2009-01-21 11:09:05 CET