[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Comment on obliterate functional specification

From: Magnus <account_at_zulutime.net>
Date: Tue, 20 Jan 2009 20:14:34 -0800 (PST)

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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.