[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Help explain peg revisions

From: Vincent Starre <vstarre_at_comcast.net>
Date: 2006-03-16 20:47:17 CET

Gale, David wrote:

>Scott Palmer wrote:
>
>
>>On 16-Mar-06, at 10:05 AM, David Heppenstall wrote:
>>
>> Do you want to checkout the 5th revision? If so:
>>
>> svn checkout <URL>@5 ... [PATH]
>>
>>
>>
>>This has come up before and I keep seeing posts that seem to
>>contradict each other.
>>
>>Shouldn't that be:
>>
>>svn checkout -r5 <url>
>>
>>
>>I thought peg revisions were for finding a path that might have a
>>different name in HEAD, not to specifiy which revision to actually
>>get. In other words, if I want to check out the HEAD revision of
>>something that had the name "foo" in rev 5 but was later renamed (to
>>some name that I don't know, otherwise I would use it) would I not
>>do:
>>
>>svn checkout url-to-foo@5
>>
>>?
>>
>>Yet in some posts, such as the one quoted above it seems to imply
>>that the peg revision will be used as if it was also passed with "-r"
>>
>>Do I have to be explicit about specifying the HEAD revision like:
>>
>>svn checkout -rHEAD url-to-foo@5
>>
>>.. if so then I missed the part in the docs that mentions this
>>exception to the rule checking out a url defaults to HEAD.
>>
>>Scott
>>
>>
>
>In the situation given (file modified between revisions 5 and 10, and we
>want to get what it was in revision 5), you only need "svn co -r5
>url-to-foo", which is equivalent to "svn co -r5 url-to-foo@HEAD", and
>which means "checkout the file currently named foo that existed in
>revision 5". The syntax given by Mr. Heppenstall (svn checkout
><URL>@5..." is wrong; it's full equivalent is "svn co -rHEAD <URL>@5",
>which means "checkout the current revision of the file that was at this
>URL at revision 5".
>
>The only time you really need to specify both a -r argument and a peg
>revision is when a file has been (potentially) deleted or moved, and you
>know what its name was at some point in the past. Your original
>understanding was correct.
>
>-David
>
>
don't mean to throw more confusion on the fire, but now /I'm/ confused :)
Since SVN implements moves as copy+delete, how would it know that:
-r3 /foo@2
means /bar (where foo was moved to) and not /baz (where foo was copied to)?
I though peg revisions were for backtracking-only, not
"forward-tracking". ie:
"What was foo like at r167?" "foo didnt exist in r167."[a new file
replaced the original foo sometime around 193] "okay, but there was a
file called foo at 167, what was /that/?"

Due to the "backtracking only" nature, I thought foo@167 meant "the node
which was called foo at revision 167", which could only be last-changed
at a revision equal-to-or-less-than 167. So technically, "svn co -r167
foo" and "svn co foo@167" could give you the same thing, assuming they
havent been moved/renamed at all. However, that said, the /purpose/ of
peg-revisions is still entirely seperate from -r, and their meanings
should definatly _NOT_ be mixed.

Of course, I could be completely, utterly, to a point beyond even the
slightest semblance of potential credibility, full of so much shit that
farmers from three states over want to use me on their crops. I really
have no idea if what I just said is accurate, that's just pretty much
how I assumed it worked based on other behaviors of svn.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 16 20:48:55 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.