Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@<rev>' syntax

[Sam Vilain <sam@vilain.net>]

On 20/07/11 10:07, Michael J Gruber wrote:
> path@REV are so-called peg revisions, introduced in svn 1.1, and denote
> "I mean the file named path in REV" (as opposed to "the file named path
> now and maybe differently back then"). It (now) defaults to BASE (for
> worktree) resp. HEAD (for URLs). A bit like our rename detection.
>
> -r REV specifies the operative revision. After resolving the
> name/location using the pegrev, the version at the resolved path at the
> oprative version is operated on.
>
> svn 1.5.0 (June 2008) introduced peg revisions to "svn copy", so I
> assume our people were following svn trunk and adjusting in 2007 already
> (to r22964). There were some fixes to "svn copy" with peg later on.
>
> I do not understand the above commit message at all; and I did not find
> anything about how "svn copy -r REV" acted in svn 1.4. I would assume
> "operative revision", and the above commit message seems to imply that
> peg defaulted to REV here (not HEAD) and that that changed in 1.5.0, but
> that is a wild guess (svnbook 1.4 does not so anything).

What happened is that I noticed that the code stopped working after svn
1.5 was released.  Previously I wrote it to detect the merge properties
as left by SVK and the experimental/contrib python script for merging. 
I was testing at times using trunk SVN versions.  You could probably
figure it out by running ffab6268^ with svn 1.4.x vs svn 1.5.x if you
cared.  My comment tries to explain what you describe above, but without
the correct terms.  I could see via experimentation what the difference
was between "-r N" and '/path@N', and that the behaviour changed in svn
1.5.  Apologies for not explaining this thoroughly enough in the
submitted description!

HTH,
Sam