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"). 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.
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.
* 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.
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".
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.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Jan 10 04:17:21 2007