Michael Sinz wrote:
> Brummer, Byron wrote:
> 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
> 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
> history - one newly added and one deleted from before.
Interesting. I'm rather surprised this condition is allowed
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
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
I agree it's annoying. I disagree that it's correct. What
be correct is this delete/add peg version identifying *both*
Yes, that opens a can of worms, but I'd argue the can was opened
a single commit was allowed to refer to the state of two objects
the same path.
But again, oh well. What's done is done and so it'll be left
the UI to deal with...
> There are other technical issues such as deleting an item is not
> the contents of the item but changing where it exists in the directory
SVN's docs give the distinct impression that the design idea was
the object's path is a matter of versioned meta-data of the
not of the parent of that object. Thus the idea of copy with
history; The changes to the path are effectively part of the
> Anyway, all of this ends up pointing out a user interface difficulty
> valid and correct consistency in behavior.
From a UI point of view this could be solved by offering a sane
to list all the peg (Add, for lack of something better) versions
on a given path.
Currently this is so cumbersome of a task with SVN that on a
any significant size it is effectively impossible. This is
the user is required to run a log from 0:HEAD on the *ENTIRE*
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
the object's parent directory, but this is incorrect as it
parent only has one peg version.
The repo I admin represents about six months work from about a
developers. In other words it's relatively small. Running a
on the entire repo (6000+ revs) takes *HOURS* currently and this
on a very high end machine (twin 64 bit Linux box, fast disks,
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
method to retrieve it?!
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jan 9 01:42:37 2007