[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-09 01:41:26 CET

Michael Sinz wrote:
> Brummer, Byron wrote:
>snip<
> The direct reason is that one can remove an object and add a different
> object at the same name in the same revision. This is a "replace"
> operation and very different from a modify. Note that the add could
be
> part of a "copy" (or "move") which means the new object has attached
> history that is not the original (deleted) object's history.
>
> While the URL is the same, these are two different objects in the
revision
> history - one newly added and one deleted from before.

        Interesting. I'm rather surprised this condition is allowed
within
        the context of a single revision. All other logically distinct
        actions on the same path are required to be split into distinct
        commits so far as I can tell. That is to say you can't commit
two modifications of the same path in the same commit revision. I
understand there is a difference wrt one object changing vs two
distinct objects, but in my view that's getting very close to
        needlessly exposing SVN internal storage details to the UI.

        Note that you can not propdel a versioned property and propset
        it back in the same commit. When you do so SVN considers the
        property value changed, not deleted and added back.

        I would have expected "svn add file.txt" if done after an
        svn delete file.txt w/o a commit to error back something along
        the lines of "upto date check failed; Object deletion already
        scheduled".

        Oh well, what's done is done and so it'll be left upto the UI
        to deal with.

> This behavior is what then requires the consistent (and annoying but
> correct) behavior that the deleted revision is not a peg revision
path.

        I agree it's annoying. I disagree that it's correct. What
would
        be correct is this delete/add peg version identifying *both*
objects.

        Yes, that opens a can of worms, but I'd argue the can was opened
when
        a single commit was allowed to refer to the state of two objects
on
        the same path.

        But again, oh well. What's done is done and so it'll be left
upto
        the UI to deal with...

> There are other technical issues such as deleting an item is not
changing
> the contents of the item but changing where it exists in the directory
> tree.

        SVN's docs give the distinct impression that the design idea was
that
        the object's path is a matter of versioned meta-data of the
object,
        not of the parent of that object. Thus the idea of copy with
        history; The changes to the path are effectively part of the
object's
        history.

> Anyway, all of this ends up pointing out a user interface difficulty
but a
> valid and correct consistency in behavior.

        From a UI point of view this could be solved by offering a sane
way
        to list all the peg (Add, for lack of something better) versions
found
        on a given path.

        Currently this is so cumbersome of a task with SVN that on a
repo of
        any significant size it is effectively impossible. This is
because
        the user is required to run a log from 0:HEAD on the *ENTIRE*
repo
        to find out the peg versions for any object (plus a fun bunch of
        filtering). It wouldn't be so bad if you could run log against
only
        the object's parent directory, but this is incorrect as it
assumes the
        parent only has one peg version.

        The repo I admin represents about six months work from about a
dozen
        developers. In other words it's relatively small. Running a
log
        on the entire repo (6000+ revs) takes *HOURS* currently and this
is
        on a very high end machine (twin 64 bit Linux box, fast disks,
etc).
        And it pegs the CPU it's run on to 99% for the duration. That's
        before any filtering to get the actual info.

        I dare say, what value is "correct" history if there is no
practical
        method to retrieve it?!

-Byron

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 9 01:42:37 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.