Good description, however can you clarify a couple of issues that I
still think are slightly up in the air?
1. Until I read this thread, I was under the impression that you can
only go _backwards_ from the peg revision, not forwards. And I just
checked all the docs I could find and that's pretty much what they all
say too. I think it would be useful to update the docs to make it clear
that you can go both forwards and backwards (with the obvious caveat
regarding broken renames).
2. Most SVN docs I can find pretty much state that the default revision
with no -r switch is HEAD. But clearly with a peg revision no -r switch
and -rHEAD give different results. Correct?
--Tim
kfogel@collab.net wrote:
> Hmm, I don't quite understand your question (I wrote "before" not
> "after"), but here's an example of what I meant:
>
> r1: add /foo
> r5: (/foo is still in the same location it's been in since r1)
> r7: rename /foo to /bar
> r8: change the contents of /bar
> r10: (no further changes to /foo or /bar, just noting that r10 is HEAD)
>
> Now:
>
> $ svn cat -rHEAD url-to-foo@5
>
> My claim is that this should cat the contents /bar has had since r8.
> We used url-to-foo@5 to identify the object (i.e., identify the "line
> of history"), and we used -rHEAD to identify what point along that
> line of history we're interested in. That point is r10 (HEAD), and as
> of r10, the object formerly known as /foo is now /bar, and has the
> contents /bar has had since r8.
>
> Clearer?
>
> But I can think of one reason why Subversion might not be able to
> behave this way today: renames are not yet perfectly implemented (see
> issues #898 and #895) and appear as just "copy + delete". As was
> pointed out elsewhere in this thread, since it's just a copy, the
> source file could have been copied to multiple destinations -- in
> which case, which of those destinations should be treated as the One
> True Inheritor of the object's ancestry?
>
> This problem is what the true renames work Garrett Rooney is doing
> will fix, among other things.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 22 03:07:34 2006