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