RFC patcht9159-*.sh: Don't use the svn '@<rev>' syntax

> Avoiding the use of the '@<rev>' syntax, in favour of an '-r <rev>'
> parameter, allows older versions of svn to execute the test.
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
>
> Hi Junio,
>
> This test is failing for me on Linux and MinGW (I don't have svn
> installed on cygwin), again (i suspect) due to the older versions
> of svn I have. [v1.4.3 on Linux and v1.4.6 on MinGW]
>
> This patch fixes the test for me. However, I noticed that there are
> two other uses of the syntax in t9104-git-svn-follow-parent.sh which
> look like this:
>
>         (svn_cmd cp -m "resurrecting trunk as junk" \
>                "$svnrepo"/trunk@2 "$svnrepo"/junk ||
>          svn cp -m "resurrecting trunk as junk" \
>                -r2 "$svnrepo"/trunk "$svnrepo"/junk) &&
>
> which, unless I'm confused (possible), has been coded specifically
> to cater to just this problem!
> However, I think the above is a little too "belt & braces" for my
> liking. What do you think?

>  t/t9159-git-svn-no-parent-mergeinfo.sh |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t9159-git-svn-no-parent-mergeinfo.sh b/t/t9159-git-svn-no-parent-mergeinfo.sh
> index 85120b7..4cf26e9 100755
> --- a/t/t9159-git-svn-no-parent-mergeinfo.sh
> +++ b/t/t9159-git-svn-no-parent-mergeinfo.sh
> @@ -11,7 +11,7 @@ test_expect_success 'test handling of root commits in merge ranges' '
>  		cd tmp &&
>  		echo "r2" > trunk/file.txt &&
>  		svn_cmd commit -m "Modify file.txt on trunk" &&
> -		svn_cmd cp trunk@1 branches/a &&
> +		svn_cmd cp -r1 trunk branches/a &&
>  		svn_cmd commit -m "Create branch a from trunk r1" &&
>  		svn_cmd propset svn:mergeinfo /trunk:1-2 branches/a &&
>  		svn_cmd commit -m "Fake merge of trunk r2 into branch a" &&
> @@ -21,7 +21,7 @@ test_expect_success 'test handling of root commits in merge ranges' '
>  		svn_cmd commit -m "Create branch b from thin air" &&
>  		echo "r6" > branches/b/file2.txt &&
>  		svn_cmd commit -m "Modify file2.txt on branch b" &&
> -		svn_cmd cp branches/b@5 branches/c &&
> +		svn_cmd cp -r5 branches/b branches/c &&
>  		svn_cmd commit -m "Create branch c from branch b r5" &&
>  		svn_cmd propset svn:mergeinfo /branches/b:5-6 branches/c &&
>  		svn_cmd commit -m "Fake merge of branch b r6 into branch c"

> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> 
>> Avoiding the use of the '@<rev>' syntax, in favour of an '-r <rev>'
>> parameter, allows older versions of svn to execute the test.
>>
>> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
>> ---
>>
>> Hi Junio,
>>
>> This test is failing for me on Linux and MinGW (I don't have svn
>> installed on cygwin), again (i suspect) due to the older versions
>> of svn I have. [v1.4.3 on Linux and v1.4.6 on MinGW]
>>
>> This patch fixes the test for me. However, I noticed that there are
>> two other uses of the syntax in t9104-git-svn-follow-parent.sh which
>> look like this:
>>
>>         (svn_cmd cp -m "resurrecting trunk as junk" \
>>                "$svnrepo"/trunk@2 "$svnrepo"/junk ||
>>          svn cp -m "resurrecting trunk as junk" \
>>                -r2 "$svnrepo"/trunk "$svnrepo"/junk) &&
>>
>> which, unless I'm confused (possible), has been coded specifically
>> to cater to just this problem!
>> However, I think the above is a little too "belt & braces" for my
>> liking. What do you think?
> 
> Hmm, but I am actually having trouble understanding what ffab626 (git-svn:
> handle changed svn command-line syntax, 2007-09-21) wanted to do.  It
> says:
> 
>     git-svn: handle changed svn command-line syntax
>     
>     Previously, if you passed a revision and a path to svn cp, it meant to look
>     back at that revision and select that path.  New behaviour is to get the
>     path then go back to the revision (like other commands that accept @REV
>     or -rREV do).  The more consistent syntax is not supported by the old
>     tools, so we have to try both in turn.
>     
>     Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
>     Acked-by: Eric Wong <normalperson@yhbt.net>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
> 
> The explanation is not making sense at all. "Go back at the revision and
> pick that path" vs "Pick the path and go back to the revision" would
> change behaviour if the path was renamed since the revision, but it is not
> like that the issue ffab626 wanted to fix was make sure which semantics is
> used by using the right syntax that uses that semantics, so why did it
> bring it up in the first place?  The first three lines and half might be
> stating the fact, but it seems utterly irrelevant to what the commit does.
> 
> I am guessing that the "more consistent syntax" in the above is trying to
> say that the author wants to see "path@REV" used as much as possible
> instead of using "-rREV". But why use path@REV if newer subversion does
> not drop support for the path@REV syntax?
> 
> Or is it "path@REV picks path and then goes to the REV, vs -rREV path goes
> to REV and picks path"? If that is the case, then "we try both in turn"
> needs a lot more explanation. If a newer subversion with path@REV support
> that follows the "file identity" of path can be used, it copies from what
> is now called "trunk" as it used to be at rev2, while an older subversion
> without it cannot do so and copies from "trunk" that was at rev2. These
> two may give vastly different results if "trunk" was renamed in between,
> no? And if there was no such rename of "trunk" that affects what would
> happen, then there is _no_ point in writing "path@REV || -rREV path" in
> the first place---we know we can always use "-rREV path" without worrying
> about what version of subversion is being used.
> 
> I am confused. Sam/Eric, care to help clarify the situation?

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

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

> Hmm, I was hoping that someone would say something like:
> 
>    "This test does not depend on the difference between the peg revision
> and the operative revision, because the history represented in the test
> repo is so simple that there *is* no difference, so Acked By: ... "

> diff --git a/t/t9159-git-svn-no-parent-mergeinfo.sh b/t/t9159-git-svn-no-parent-mergeinfo.sh
> index 85120b7..69e4815 100755
> --- a/t/t9159-git-svn-no-parent-mergeinfo.sh
> +++ b/t/t9159-git-svn-no-parent-mergeinfo.sh
> @@ -2,6 +2,14 @@
>  test_description='git svn handling of root commits in merge ranges'
>  . ./lib-git-svn.sh
>  
> +svn_ver="$(svn --version --quiet)"
> +case $svn_ver in
> +0.* | 1.[0-4].*)
> +	skip_all="skipping git-svn test - SVN too old ($svn_ver)"
> +	test_done
> +	;;
> +esac
> +
>  test_expect_success 'test handling of root commits in merge ranges' '
>  	mkdir -p init/trunk init/branches init/tags &&
>  	echo "r1" > init/trunk/file.txt &&
> -- 

> Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>> Hmm, I was hoping that someone would say something like:
>>
>>    "This test does not depend on the difference between the peg revision
>> and the operative revision, because the history represented in the test
>> repo is so simple that there *is* no difference, so Acked By: ... "
>
> Unfortunately, I remain perpetually confused w.r.t peg revisions vs "-r"
> and how it's handled differently between different SVN versions.