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

[Ramsay Jones <ramsay@ramsay1.demon.co.uk>]

Sam Vilain wrote:
> 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: ... "

But, since that didn't happen, maybe the patch given below would be more
acceptable? (I personally prefer the original patch ...)

Given that I didn't quite follow Sam's explanation, I still don't know
if t9104-git-svn-follow-parent.sh needs to be changed (again, this test
*passes* for me), so ... :-P

ATB,
Ramsay Jones

-- >8 --
Subject: [PATCH] t9159-*.sh: Add an svn version check


Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
 t/t9159-git-svn-no-parent-mergeinfo.sh |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

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 &&
-- 
1.7.6