[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: Scott Palmer <scott.palmer_at_2connected.org>
Date: 2006-03-16 21:02:33 CET

On 16-Mar-06, at 2:47 PM, Vincent Starre wrote:

> Gale, David wrote:
>> 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/?"

I think you are correct. Now that I think about it a bit more it is
obvious that there can be multiple future paths that foo is copied to
and since subversion doesn't have true renames it wouldn't know which
path was the "true" path.

> 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.

Yes, I think you understand it well. Though peg revision puts a
limit on the latest revision that it will get that can be overridden
with -r, so it is more of a side effect. Even if you do NOT rename
or move foo the peg revision syntax will limit the revision you get
to the revision specified by the peg revision, not HEAD.

It's definitely something that needs clarification.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 16 21:05:30 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.