Brummer, Byron wrote:
> A peg revision refers to the Add revision of the object and all Modified
> changes to it, but for some reason leaves the Delete revision off? The
> deletion of an object is directly related to that object more then any
> other object, yet SVN apparently believes it's only a concern of the
> object's parent directory?
>
> If url://some/file.txt was Deleted in rev 1234 it makes no sense why
> running:
>
> svn log -r 1234 url://some/file.txt
I used to think this was a problem - and still believe there needs to be some
solution but there is at least one reason this is harder than it looks.
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.
This behavior is what then requires the consistent (and annoying but correct)
behavior that the deleted revision is not a peg revision path.
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. (Or, in
this case, where is no longer exists.) This can be seen with "svn mv" which is
really a "svn cp" and "svn rm" (currently - this is being addressed) and the "svn
cp" is really an "svn add" with history. (in simplistic terms)
Anyway, all of this ends up pointing out a user interface difficulty but a valid
and correct consistency in behavior.
Maybe there would need to be a way to address this from the user interface, but
then there would still be confusion as to what to do of the case of a delete/add
in the same revision. So, even trying to solve the user interface problem is
difficult as you would need to know which of the two same named objects one is
trying to identify.
> Does not produce the log entry for that Deletion? In fact there
> apparently is no method whatsoever get the log entry for 1234 using the
> file's path, svn demands you use the parent path (assuming (danger!!!)
> that the HEAD version of the parent path is the same peg version as the
> parent path as existed at rev 1234). If you're just pulling the log of
> a single rev you could just point to the base repo url, but if you're
> pulling a range like 1100:1234 it gets ugly fast if you're trying to
> just get the log history for some/file.txt. -Same goes for pulling the
> parent directory; you have to do a lot of hacky filtering to get the
> information that SVN should clearly be able to give you directly.
>
> In some ways this is related to issue 928, but not completely. A peg
> version should include:
>
> The creation (Add) of the object.
> The changes (Modified) to the object.
> The removal (Deletion) of the object.
>
> Comments?
Yes, I agree it seems wrong. However, I don't see how it could be "fixed" given
that the behavior is correctly consistent with the behaviors and capabilities of
Subversion.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
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:01:54 2007