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

RE: Delete revision of an object has no peg revision?

From: Brummer, Byron <ByronBrummer_at_LiveNation.com>
Date: 2007-01-10 22:03:02 CET

C. Michael Pilato [mailto:cmpilato@collab.net] wrote:
> Brummer, Byron wrote:
> > It makes no sense to
> > claim to present the history of something and yet
> > rip out the last chapter leaving the book incomplete.
> > Would you teach about WWII without covering how it
> > ended, or if it ended at all?!
>
> 'svn delete' of an item is not technically the end of its story
> -- you can always copy the last visible revision of the object
> back out into addressable space (what we call "resurrecting a
> deleted item").

    Sure. That still doesn't change the fact that the removal
    of an object *is* part of the logical history of that object.
    Just as its resurrection is part of the logical history of
    that object.

    I'd also like to note the resurrection of an object neither
    changes it nor "initializes" it. Following your logic then
    the resurrection of an object should not show up in the
    object's history either, yet it does.

    Ship's log:
        Jan 10, 1954 - Ship built
        Jan 14, 1954 - Ship sailed from foo to bar
        Jan 20, 1954 - Ship sailed from bar to duh
        Feb 50, 1954 - Ship raised from the ocean floor

    Wait...what, raised? When did the ship sink? Doesn't a
    ship have to sink before it can be raised?

    Ocean's log:
        Jan 24, 1954 - Ship sank

    Yes, a history of the ocean should include the sinking of
    a ship in it. But logically the sinking of the ship is also
    part of the *ship's* history. To pretend that it isn't
    is simply wrong.
   
> When
> you do this, you find that querying the history of the item
> shows no record of having ever been deleted. Why? Because
> that wasn't a change to the object.

    The creation of an object isn't a change to the object
    either, but it *is* part of the logical history of the
    object. Same for the resurrection.

> You mentioned in your mail some seeming inconsistencies:
> * that we list an items first revision. This might seem
> inconsistent, but while the addition of a new child is
> (like deletion) a change to the containing directory, the
> initialization of that child's content and properties is
> not. In Subversion, you cannot add a new file without the
> subsystem automatically performing initialization of the
> file's contents, if only to nothing. Hence the listing.

    If initialization is a change, logically so is
    de-initialization. They are both changes to the *state* of
    the object. In fact it's the most important state change
    of all: The existence or non-existence of the object.

    Regardless both events are historical aspects of the object.
    You can argue they are *additionally* historical aspects of
    the object's parent directory, but you can not logically
    argue that they are unrelated to the object itself.

> * that we list copies and moves of an object that wasn't
> otherwise changed. Actually, we didn't use to do this.
> This functionality was added at a later date because (back
> then) Subversion's ability to deal with lines of history
> that had copies and moves in them was so pathetic that
> folks simply couldn't deal

    You mean much like SVN's current ability to query the
    history of any object which the HEAD revision isn't the PEG
    revision is so pathetic.

> But beyond all this technical haggling there's the small
> problem of the replace functionality. In Subversion, the
> "coordinates" given by (path, revision) are guaranteed (by
> design) to be unique. It is unacceptable
> to allow 'svn log path@DELETED-REV' to mean two different
> things (either "get my the logs of that path I deleted" or "get
> me the logs of the thing I replaced it with in the same
> revision I deleted it".

    It was a design flaw to allow a delete and add of the same
    path within the context of a single revision. But what is
    done is done, c'est la vie. It should be pointed out that
    in a Replace operation the single revision DOES currently
    refer to BOTH objects (rev and rev -1) by using the action
    'R'.

    Nonetheless:

        svn log -r DELETED-REV path

    Has no excuse for not actually returning the log entry,
    even in the case of a Replace. Even worse is:

        svn log -r REV_IN_WHICH_PATH_DID_EXIST path

    when path no longer exists @HEAD or @BASE. I'd say the
    peg version defaults are wrong...but that wouldn't help,
    since there's no peg version in the system that will make
    the above request return the entry.

    Asking to *UPDATE* an object to a particular revision and
    asking about the HISTORY of a particular revision are NOT
    the same thing. In any other tool asking for the log of
    a revision of an object's deletion returns that log entry,
    while asking to update the working copy of that same object
    revision obviously returns either nothing (working copy is
    made to not exist) or returns the new (Replaced with)
    revision.

    If you want the object itself, use update, cat, whatever.
    What we are talking about is the *HISTORY* of the object
    when we use the log command. What you are arguing is that
    the second most important point in an object's history is
    somehow not part of that object's history.

> I don't want to sound insensitive -- the situation you describe
> is a frustrating one. It just also happens to be engulfed in
> complexity that reaches into the very core of Subversion's
> design.

    I'm mostly surprised that such a huge, gapping, puss-oozing
    scab of missing functionality would be so completely and
    totally overlooked and ignored. SVN is at its heart a
    historical database and so it boggles the mind that reporting
    on most anything other then the HEAD revision is such a major
    pita. This current topic is but one of many such major
    issues with reporting in svn. Another fun one is trying to
    get a log range for changes from one tag to another
    because of the way SVN has chosen to implement labels. I'll
    save that one for another thread however, this thread is
    already silly enough.

-Byron

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 10 22:03:41 2007

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.