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