[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-01-10 04:16:53 CET

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:03 2007

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