Magnus,
As I saw no other response, I'll just speak up and mention that your
proposal sounds extremely sensible. I haven't followed the previous
history or proposals of the feature, though.
Of course, the test of whether your proposal really does simplify the
whole thing is in the details of what OBLITERATION SETS are needed, and
how they can be constructed, to satisfy the end-user goals.
Can I encourage you to submit a patch to the document, that incorporates
your proposal and at least makes a start on describing how it is used to
solve the goals? Or write a second proposal that we can check in beside
the existing one.
- Julian
On Tue, 2009-01-20 at 20:14 -0800, Magnus wrote:
> 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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1104601
Received on 2009-02-05 00:00:15 CET