Frodak Baksik wrote:
> Thinking about this more, you almost never want the behavior you describe.
>
> For instance, lets say you have file foo in r10, delete it in r11, and
> then:
> svn cp -r10 file:///repo/trunk/foo file:///repo/trunk to restore it in r14.
This command will fail actually; you have to use a peg revision since
the name /repo/trunk/foo does not exist in HEAD.
> When you perform the ls, cp, diff, etc commands, for versions 11, 12,
> 13 you want it to say it does not exist in those versions.
No, you don't. The file did exist in those revisions, it simply had no
name in any directory in that revision. Once you resolve the name ( in
HEAD or any other specified peg revision ), you are supposed to be able
to retrieve the state of that file in any rev as far back as the log
shows the file was created in.
> Then in r15 you delete the file again and then in r17 you restore
> version 10 again:
> svn cp -r10 file:///repo/trunk/foo file:///repo/trunk
>
> What should the command log -r14 file:///repo/trunk/foo return?
It will show that the file was copied in rev 17, from rev 10, and track
the history back from there. If you wanted to access the file that was
restored, modified, and deleted, then you have to refer to that file
with a peg revision. This is how it works now and I am perfectly fine
with that.
> It should return that it could not find the object in r14, because r14
> object is from a different line of history then the HEAD object.
No. When you don't specify a peg revision, the name is resolved in
HEAD. The object to which that name refers DID exist in r14, since it
was created prior to that. While this is not the same object that held
that name in r14, it did exist as of r14.
> As of now, SVN seems to be fairly consistent, an object does not exist
> between the version it was copied from and the version it was copied
> to.
Yes, it consistently leaves a hole in the history of the file when it is
copied. This hole breaks a number of expectations of both users and
tools. For instance, -rPREV assumes that it can find HEAD-1, so fails
in this case. If holes in the revision history were allowed, then
resolving PREV would have to fetch the log and find the last revision it
was changed in, but this is not the case. Instead it seems to be held
as an invariant that access to a file in revisions in which it was not
modified should work.
> I.E
> $ svn log file_1.txt -v
> ------------------------------------------------------------------------
> r18 | fbaksik | 2007-02-17 08:58:02 -0500 (Sat, 17 Feb 2007) | 1 line
> Changed paths:
> A /trunk/main/file_1.txt (from /trunk/main/file_1.txt:13)
>
> Restore file again.
>
> Any reference, of r14 to r17 (inclusive), will return an object not
> found type of error.
Does, but should not. Only @14 to @17 should do this because the NAME
did not exist in those revisions, but the FILE ( which is found in the
HEAD revision ) DID exist in those revisions.
> What you are asking for is to break this simple rule and say, if the
> object I copy from is a different path than what I copy to, then say
> the object does exist! But even this is not a hard and fast rule
> because if you folder renames the same time you do add or deletes,
> it'll look like you are copying from a different path when you're not.
No, it has nothing to do with whether or not the paths are different.
The problem is that an add-with-history operation leaves a hole in the
file history between the rev the history is copied from, and the rev
that the copy is performed in. This hole needs to be bridged at the
time of the copy so that the file's state can be accessed in those
revisions, as it existed in the last revision it was modified in prior
to the rev it is copied from.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 19 22:31:03 2007