{"thread":{"id":"27829","subject":"[RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","startedAt":"2011-07-16T18:04:05Z","lastAt":"2011-09-13T17:14:20Z","messageCount":10,"participants":["Ramsay Jones","Junio C Hamano","Michael J Gruber","Sam Vilain","Eric Wong","John Szakmeister"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"171486","messageId":"4E21D295.7020600@ramsay1.demon.co.uk","threadId":"27829","inReplyTo":null,"subject":"[RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2011-07-16T18:04:05Z","receivedAt":"2011-07-16T18:04:05Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\nAvoiding the use of the '@' syntax, in favour of an '-r '\nparameter, allows older versions of svn to execute the test.\n\nSigned-off-by: Ramsay Jones \n---\n\nHi Junio,\n\nThis test is failing for me on Linux and MinGW (I don't have svn\ninstalled on cygwin), again (i suspect) due to the older versions\nof svn I have. [v1.4.3 on Linux and v1.4.6 on MinGW]\n\nThis patch fixes the test for me. However, I noticed that there are\ntwo other uses of the syntax in t9104-git-svn-follow-parent.sh which\nlook like this:\n\n (svn_cmd cp -m \"resurrecting trunk as junk\" \\\n \"$svnrepo\"/trunk@2 \"$svnrepo\"/junk ||\n svn cp -m \"resurrecting trunk as junk\" \\\n -r2 \"$svnrepo\"/trunk \"$svnrepo\"/junk) &&\n\nwhich, unless I'm confused (possible), has been coded specifically\nto cater to just this problem!\n\nHowever, I think the above is a little too \"belt & braces\" for my\nliking. What do you think?\n\nHmm, I've just found commit ffab62681 (git-svn: handle changed svn\ncommand-line syntax, 21-09-2007), which seems to imply that the\nabove is necessary due to a change in behaviour. I'm afraid I don't\nknow svn much at all; the only reason it is installed on Linux is\nto improve test coverage of git! :-P\n\nSo, maybe this patch should do the same as above (which is the reason\nfor the RFC); dunno ...\n\nHopefully, someone who knows svn can pick this up and make a proper patch.\n\nATB,\nRamsay Jones\n\n t/t9159-git-svn-no-parent-mergeinfo.sh | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/t/t9159-git-svn-no-parent-mergeinfo.sh b/t/t9159-git-svn-no-parent-mergeinfo.sh\nindex 85120b7..4cf26e9 100755\n--- a/t/t9159-git-svn-no-parent-mergeinfo.sh\n+++ b/t/t9159-git-svn-no-parent-mergeinfo.sh\n@@ -11,7 +11,7 @@ test_expect_success 'test handling of root commits in merge ranges' '\n \t\tcd tmp &&\n \t\techo \"r2\" > trunk/file.txt &&\n \t\tsvn_cmd commit -m \"Modify file.txt on trunk\" &&\n-\t\tsvn_cmd cp trunk@1 branches/a &&\n+\t\tsvn_cmd cp -r1 trunk branches/a &&\n \t\tsvn_cmd commit -m \"Create branch a from trunk r1\" &&\n \t\tsvn_cmd propset svn:mergeinfo /trunk:1-2 branches/a &&\n \t\tsvn_cmd commit -m \"Fake merge of trunk r2 into branch a\" &&\n@@ -21,7 +21,7 @@ test_expect_success 'test handling of root commits in merge ranges' '\n \t\tsvn_cmd commit -m \"Create branch b from thin air\" &&\n \t\techo \"r6\" > branches/b/file2.txt &&\n \t\tsvn_cmd commit -m \"Modify file2.txt on branch b\" &&\n-\t\tsvn_cmd cp branches/b@5 branches/c &&\n+\t\tsvn_cmd cp -r5 branches/b branches/c &&\n \t\tsvn_cmd commit -m \"Create branch c from branch b r5\" &&\n \t\tsvn_cmd propset svn:mergeinfo /branches/b:5-6 branches/c &&\n \t\tsvn_cmd commit -m \"Fake merge of branch b r6 into branch c\"\n-- \n1.7.6\n"},{"id":"171697","messageId":"7vvcuy82kn.fsf@alter.siamese.dyndns.org","threadId":"27829","inReplyTo":"4E21D295.7020600@ramsay1.demon.co.uk","subject":"Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-07-19T19:58:48Z","receivedAt":"2011-07-19T19:58:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramsay Jones writes:\n\n> Avoiding the use of the '@' syntax, in favour of an '-r '\n> parameter, allows older versions of svn to execute the test.\n>\n> Signed-off-by: Ramsay Jones \n> ---\n>\n> Hi Junio,\n>\n> This test is failing for me on Linux and MinGW (I don't have svn\n> installed on cygwin), again (i suspect) due to the older versions\n> of svn I have. [v1.4.3 on Linux and v1.4.6 on MinGW]\n>\n> This patch fixes the test for me. However, I noticed that there are\n> two other uses of the syntax in t9104-git-svn-follow-parent.sh which\n> look like this:\n>\n> (svn_cmd cp -m \"resurrecting trunk as junk\" \\\n> \"$svnrepo\"/trunk@2 \"$svnrepo\"/junk ||\n> svn cp -m \"resurrecting trunk as junk\" \\\n> -r2 \"$svnrepo\"/trunk \"$svnrepo\"/junk) &&\n>\n> which, unless I'm confused (possible), has been coded specifically\n> to cater to just this problem!\n> However, I think the above is a little too \"belt & braces\" for my\n> liking. What do you think?\n\nHmm, but I am actually having trouble understanding what ffab626 (git-svn:\nhandle changed svn command-line syntax, 2007-09-21) wanted to do. It\nsays:\n\n git-svn: handle changed svn command-line syntax\n \n Previously, if you passed a revision and a path to svn cp, it meant to look\n back at that revision and select that path. New behaviour is to get the\n path then go back to the revision (like other commands that accept @REV\n or -rREV do). The more consistent syntax is not supported by the old\n tools, so we have to try both in turn.\n \n Signed-off-by: Sam Vilain \n Acked-by: Eric Wong \n Signed-off-by: Junio C Hamano \n\nThe explanation is not making sense at all. \"Go back at the revision and\npick that path\" vs \"Pick the path and go back to the revision\" would\nchange behaviour if the path was renamed since the revision, but it is not\nlike that the issue ffab626 wanted to fix was make sure which semantics is\nused by using the right syntax that uses that semantics, so why did it\nbring it up in the first place? The first three lines and half might be\nstating the fact, but it seems utterly irrelevant to what the commit does.\n\nI am guessing that the \"more consistent syntax\" in the above is trying to\nsay that the author wants to see \"path@REV\" used as much as possible\ninstead of using \"-rREV\". But why use path@REV if newer subversion does\nnot drop support for the path@REV syntax?\n\nOr is it \"path@REV picks path and then goes to the REV, vs -rREV path goes\nto REV and picks path\"? If that is the case, then \"we try both in turn\"\nneeds a lot more explanation. If a newer subversion with path@REV support\nthat follows the \"file identity\" of path can be used, it copies from what\nis now called \"trunk\" as it used to be at rev2, while an older subversion\nwithout it cannot do so and copies from \"trunk\" that was at rev2. These\ntwo may give vastly different results if \"trunk\" was renamed in between,\nno? And if there was no such rename of \"trunk\" that affects what would\nhappen, then there is _no_ point in writing \"path@REV || -rREV path\" in\nthe first place---we know we can always use \"-rREV path\" without worrying\nabout what version of subversion is being used.\n\nI am confused. Sam/Eric, care to help clarify the situation?\n\nI also recall that svn:mergeinfo support is relatively new; is it even\nsupported in a old version that did not understand trunk@1 syntax?\n\n> t/t9159-git-svn-no-parent-mergeinfo.sh | 4 ++--\n> 1 files changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/t/t9159-git-svn-no-parent-mergeinfo.sh b/t/t9159-git-svn-no-parent-mergeinfo.sh\n> index 85120b7..4cf26e9 100755\n> --- a/t/t9159-git-svn-no-parent-mergeinfo.sh\n> +++ b/t/t9159-git-svn-no-parent-mergeinfo.sh\n> @@ -11,7 +11,7 @@ test_expect_success 'test handling of root commits in merge ranges' '\n> \t\tcd tmp &&\n> \t\techo \"r2\" > trunk/file.txt &&\n> \t\tsvn_cmd commit -m \"Modify file.txt on trunk\" &&\n> -\t\tsvn_cmd cp trunk@1 branches/a &&\n> +\t\tsvn_cmd cp -r1 trunk branches/a &&\n> \t\tsvn_cmd commit -m \"Create branch a from trunk r1\" &&\n> \t\tsvn_cmd propset svn:mergeinfo /trunk:1-2 branches/a &&\n> \t\tsvn_cmd commit -m \"Fake merge of trunk r2 into branch a\" &&\n> @@ -21,7 +21,7 @@ test_expect_success 'test handling of root commits in merge ranges' '\n> \t\tsvn_cmd commit -m \"Create branch b from thin air\" &&\n> \t\techo \"r6\" > branches/b/file2.txt &&\n> \t\tsvn_cmd commit -m \"Modify file2.txt on branch b\" &&\n> -\t\tsvn_cmd cp branches/b@5 branches/c &&\n> +\t\tsvn_cmd cp -r5 branches/b branches/c &&\n> \t\tsvn_cmd commit -m \"Create branch c from branch b r5\" &&\n> \t\tsvn_cmd propset svn:mergeinfo /branches/b:5-6 branches/c &&\n> \t\tsvn_cmd commit -m \"Fake merge of branch b r6 into branch c\"\n"},{"id":"171727","messageId":"4E269AB6.8070207@drmicha.warpmail.net","threadId":"27829","inReplyTo":"7vvcuy82kn.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-07-20T09:07:02Z","receivedAt":"2011-07-20T09:07:02Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 19.07.2011 21:58:\n> Ramsay Jones writes:\n> \n>> Avoiding the use of the '@' syntax, in favour of an '-r '\n>> parameter, allows older versions of svn to execute the test.\n>>\n>> Signed-off-by: Ramsay Jones \n>> ---\n>>\n>> Hi Junio,\n>>\n>> This test is failing for me on Linux and MinGW (I don't have svn\n>> installed on cygwin), again (i suspect) due to the older versions\n>> of svn I have. [v1.4.3 on Linux and v1.4.6 on MinGW]\n>>\n>> This patch fixes the test for me. However, I noticed that there are\n>> two other uses of the syntax in t9104-git-svn-follow-parent.sh which\n>> look like this:\n>>\n>> (svn_cmd cp -m \"resurrecting trunk as junk\" \\\n>> \"$svnrepo\"/trunk@2 \"$svnrepo\"/junk ||\n>> svn cp -m \"resurrecting trunk as junk\" \\\n>> -r2 \"$svnrepo\"/trunk \"$svnrepo\"/junk) &&\n>>\n>> which, unless I'm confused (possible), has been coded specifically\n>> to cater to just this problem!\n>> However, I think the above is a little too \"belt & braces\" for my\n>> liking. What do you think?\n> \n> Hmm, but I am actually having trouble understanding what ffab626 (git-svn:\n> handle changed svn command-line syntax, 2007-09-21) wanted to do. It\n> says:\n> \n> git-svn: handle changed svn command-line syntax\n> \n> Previously, if you passed a revision and a path to svn cp, it meant to look\n> back at that revision and select that path. New behaviour is to get the\n> path then go back to the revision (like other commands that accept @REV\n> or -rREV do). The more consistent syntax is not supported by the old\n> tools, so we have to try both in turn.\n> \n> Signed-off-by: Sam Vilain \n> Acked-by: Eric Wong \n> Signed-off-by: Junio C Hamano \n> \n> The explanation is not making sense at all. \"Go back at the revision and\n> pick that path\" vs \"Pick the path and go back to the revision\" would\n> change behaviour if the path was renamed since the revision, but it is not\n> like that the issue ffab626 wanted to fix was make sure which semantics is\n> used by using the right syntax that uses that semantics, so why did it\n> bring it up in the first place? The first three lines and half might be\n> stating the fact, but it seems utterly irrelevant to what the commit does.\n> \n> I am guessing that the \"more consistent syntax\" in the above is trying to\n> say that the author wants to see \"path@REV\" used as much as possible\n> instead of using \"-rREV\". But why use path@REV if newer subversion does\n> not drop support for the path@REV syntax?\n> \n> Or is it \"path@REV picks path and then goes to the REV, vs -rREV path goes\n> to REV and picks path\"? If that is the case, then \"we try both in turn\"\n> needs a lot more explanation. If a newer subversion with path@REV support\n> that follows the \"file identity\" of path can be used, it copies from what\n> is now called \"trunk\" as it used to be at rev2, while an older subversion\n> without it cannot do so and copies from \"trunk\" that was at rev2. These\n> two may give vastly different results if \"trunk\" was renamed in between,\n> no? And if there was no such rename of \"trunk\" that affects what would\n> happen, then there is _no_ point in writing \"path@REV || -rREV path\" in\n> the first place---we know we can always use \"-rREV path\" without worrying\n> about what version of subversion is being used.\n> \n> I am confused. Sam/Eric, care to help clarify the situation?\n\npath@REV are so-called peg revisions, introduced in svn 1.1, and denote\n\"I mean the file named path in REV\" (as opposed to \"the file named path\nnow and maybe differently back then\"). It (now) defaults to BASE (for\nworktree) resp. HEAD (for URLs). A bit like our rename detection.\n\n-r REV specifies the operative revision. After resolving the\nname/location using the pegrev, the version at the resolved path at the\noprative version is operated on.\n\nsvn 1.5.0 (June 2008) introduced peg revisions to \"svn copy\", so I\nassume our people were following svn trunk and adjusting in 2007 already\n(to r22964). There were some fixes to \"svn copy\" with peg later on.\n\nI do not understand the above commit message at all; and I did not find\nanything about how \"svn copy -r REV\" acted in svn 1.4. I would assume\n\"operative revision\", and the above commit message seems to imply that\npeg defaulted to REV here (not HEAD) and that that changed in 1.5.0, but\nthat is a wild guess (svnbook 1.4 does not so anything).\n\n> I also recall that svn:mergeinfo support is relatively new; is it even\n> supported in a old version that did not understand trunk@1 syntax?\n\nWhile that is true, the said test sets the svn:mergeinfo property and\ncommits it (which you can do with any svn that knows properties), and\nthen tests whether our own \"git svn init -s && git svn fetch\" can grok\nthat, which only needs a property-reading svn (-binding). So, this does\nnot need subversion's merge support at all.\n\nCheers,\nMichael\n"},{"id":"171728","messageId":"4E269B7E.5030906@drmicha.warpmail.net","threadId":"27829","inReplyTo":"7vvcuy82kn.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-07-20T09:10:22Z","receivedAt":"2011-07-20T09:10:22Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"And here's just a ping post with Sam's *correct* address so that he's\nnot shut out but aware of the thread...\n"},{"id":"171736","messageId":"4E26D850.5030403@drmicha.warpmail.net","threadId":"27829","inReplyTo":"4E269B7E.5030906@drmicha.warpmail.net","subject":"Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-07-20T13:29:52Z","receivedAt":"2011-07-20T13:29:52Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael J Gruber venit, vidit, dixit 20.07.2011 11:10:\n> And here's just a ping post with Sam's *correct* address so that he's\n\nOr so I thought. Last try. Promised.\n\n> not shut out but aware of the thread...\n"},{"id":"171742","messageId":"4E27098B.906@vilain.net","threadId":"27829","inReplyTo":"4E269AB6.8070207@drmicha.warpmail.net","subject":"Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2011-07-20T16:59:55Z","receivedAt":"2011-07-20T16:59:55Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On 20/07/11 10:07, Michael J Gruber wrote:\n> path@REV are so-called peg revisions, introduced in svn 1.1, and denote\n> \"I mean the file named path in REV\" (as opposed to \"the file named path\n> now and maybe differently back then\"). It (now) defaults to BASE (for\n> worktree) resp. HEAD (for URLs). A bit like our rename detection.\n>\n> -r REV specifies the operative revision. After resolving the\n> name/location using the pegrev, the version at the resolved path at the\n> oprative version is operated on.\n>\n> svn 1.5.0 (June 2008) introduced peg revisions to \"svn copy\", so I\n> assume our people were following svn trunk and adjusting in 2007 already\n> (to r22964). There were some fixes to \"svn copy\" with peg later on.\n>\n> I do not understand the above commit message at all; and I did not find\n> anything about how \"svn copy -r REV\" acted in svn 1.4. I would assume\n> \"operative revision\", and the above commit message seems to imply that\n> peg defaulted to REV here (not HEAD) and that that changed in 1.5.0, but\n> that is a wild guess (svnbook 1.4 does not so anything).\n\nWhat happened is that I noticed that the code stopped working after svn\n1.5 was released. Previously I wrote it to detect the merge properties\nas left by SVK and the experimental/contrib python script for merging. \nI was testing at times using trunk SVN versions. You could probably\nfigure it out by running ffab6268^ with svn 1.4.x vs svn 1.5.x if you\ncared. My comment tries to explain what you describe above, but without\nthe correct terms. I could see via experimentation what the difference\nwas between \"-r N\" and '/path@N', and that the behaviour changed in svn\n1.5. Apologies for not explaining this thoroughly enough in the\nsubmitted description!\n\nHTH,\nSam\n"},{"id":"175279","messageId":"4E6BA0FA.9070103@ramsay1.demon.co.uk","threadId":"27829","inReplyTo":"4E27098B.906@vilain.net","subject":"Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2011-09-10T17:40:10Z","receivedAt":"2011-09-10T17:40:10Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Sam Vilain wrote:\n> On 20/07/11 10:07, Michael J Gruber wrote:\n>> path@REV are so-called peg revisions, introduced in svn 1.1, and denote\n>> \"I mean the file named path in REV\" (as opposed to \"the file named path\n>> now and maybe differently back then\"). It (now) defaults to BASE (for\n>> worktree) resp. HEAD (for URLs). A bit like our rename detection.\n>>\n>> -r REV specifies the operative revision. After resolving the\n>> name/location using the pegrev, the version at the resolved path at the\n>> oprative version is operated on.\n>>\n>> svn 1.5.0 (June 2008) introduced peg revisions to \"svn copy\", so I\n>> assume our people were following svn trunk and adjusting in 2007 already\n>> (to r22964). There were some fixes to \"svn copy\" with peg later on.\n>>\n>> I do not understand the above commit message at all; and I did not find\n>> anything about how \"svn copy -r REV\" acted in svn 1.4. I would assume\n>> \"operative revision\", and the above commit message seems to imply that\n>> peg defaulted to REV here (not HEAD) and that that changed in 1.5.0, but\n>> that is a wild guess (svnbook 1.4 does not so anything).\n> \n> What happened is that I noticed that the code stopped working after svn\n> 1.5 was released. Previously I wrote it to detect the merge properties\n> as left by SVK and the experimental/contrib python script for merging. \n> I was testing at times using trunk SVN versions. You could probably\n> figure it out by running ffab6268^ with svn 1.4.x vs svn 1.5.x if you\n> cared. My comment tries to explain what you describe above, but without\n> the correct terms. I could see via experimentation what the difference\n> was between \"-r N\" and '/path@N', and that the behaviour changed in svn\n> 1.5. Apologies for not explaining this thoroughly enough in the\n> submitted description!\n\nHmm, I was hoping that someone would say something like:\n\n \"This test does not depend on the difference between the peg revision\nand the operative revision, because the history represented in the test\nrepo is so simple that there *is* no difference, so Acked By: ... \"\n\nBut, since that didn't happen, maybe the patch given below would be more\nacceptable? (I personally prefer the original patch ...)\n\nGiven that I didn't quite follow Sam's explanation, I still don't know\nif t9104-git-svn-follow-parent.sh needs to be changed (again, this test\n*passes* for me), so ... :-P\n\nATB,\nRamsay Jones\n\n-- >8 --\nSubject: [PATCH] t9159-*.sh: Add an svn version check\n\n\nSigned-off-by: Ramsay Jones \n---\n t/t9159-git-svn-no-parent-mergeinfo.sh | 8 ++++++++\n 1 files changed, 8 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t9159-git-svn-no-parent-mergeinfo.sh b/t/t9159-git-svn-no-parent-mergeinfo.sh\nindex 85120b7..69e4815 100755\n--- a/t/t9159-git-svn-no-parent-mergeinfo.sh\n+++ b/t/t9159-git-svn-no-parent-mergeinfo.sh\n@@ -2,6 +2,14 @@\n test_description='git svn handling of root commits in merge ranges'\n . ./lib-git-svn.sh\n \n+svn_ver=\"$(svn --version --quiet)\"\n+case $svn_ver in\n+0.* | 1.[0-4].*)\n+\tskip_all=\"skipping git-svn test - SVN too old ($svn_ver)\"\n+\ttest_done\n+\t;;\n+esac\n+\n test_expect_success 'test handling of root commits in merge ranges' '\n \tmkdir -p init/trunk init/branches init/tags &&\n \techo \"r1\" > init/trunk/file.txt &&\n-- \n1.7.6\n"},{"id":"175389","messageId":"20110913075726.GA15066@dcvr.yhbt.net","threadId":"27829","inReplyTo":"4E6BA0FA.9070103@ramsay1.demon.co.uk","subject":"Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2011-09-13T07:57:26Z","receivedAt":"2011-09-13T07:57:26Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Ramsay Jones wrote:\n> Hmm, I was hoping that someone would say something like:\n> \n> \"This test does not depend on the difference between the peg revision\n> and the operative revision, because the history represented in the test\n> repo is so simple that there *is* no difference, so Acked By: ... \"\n\nUnfortunately, I remain perpetually confused w.r.t peg revisions vs \"-r\"\nand how it's handled differently between different SVN versions.\n\n> But, since that didn't happen, maybe the patch given below would be more\n> acceptable? (I personally prefer the original patch ...)\n\nI'm much more comfortable with your below patch as it won't break\non newer (and increasingly more widely-used) versions.\n\n> Given that I didn't quite follow Sam's explanation, I still don't know\n> if t9104-git-svn-follow-parent.sh needs to be changed (again, this test\n> *passes* for me), so ... :-P\n\n> Subject: [PATCH] t9159-*.sh: Add an svn version check\n\nHow about something along the lines of:\n\n Subject: [PATCH] t9159-*.sh: skip for mergeinfo test for svn <= 1.4\n\n t9159 relies on the command-line syntax of svn >= 1.5.\n Given the declining install base of older svn versions,\n it is not worth our time to support older svn syntax.\n\n Acked-by: Eric Wong \n Signed-off-by: Ramsay Jones \n\n?\n\n> diff --git a/t/t9159-git-svn-no-parent-mergeinfo.sh b/t/t9159-git-svn-no-parent-mergeinfo.sh\n> index 85120b7..69e4815 100755\n> --- a/t/t9159-git-svn-no-parent-mergeinfo.sh\n> +++ b/t/t9159-git-svn-no-parent-mergeinfo.sh\n> @@ -2,6 +2,14 @@\n> test_description='git svn handling of root commits in merge ranges'\n> . ./lib-git-svn.sh\n> \n> +svn_ver=\"$(svn --version --quiet)\"\n> +case $svn_ver in\n> +0.* | 1.[0-4].*)\n> +\tskip_all=\"skipping git-svn test - SVN too old ($svn_ver)\"\n> +\ttest_done\n> +\t;;\n> +esac\n> +\n> test_expect_success 'test handling of root commits in merge ranges' '\n> \tmkdir -p init/trunk init/branches init/tags &&\n> \techo \"r1\" > init/trunk/file.txt &&\n> -- \n"},{"id":"175393","messageId":"CAEBDL5W3pEz6Bcdt3B1PPvbF_HrvgXTLbaNUCeR=+M5bUgRJSw@mail.gmail.com","threadId":"27829","inReplyTo":"20110913075726.GA15066@dcvr.yhbt.net","subject":"Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2011-09-13T09:15:00Z","receivedAt":"2011-09-13T09:15:00Z","isPatch":true,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Tue, Sep 13, 2011 at 3:57 AM, Eric Wong wrote:\n> Ramsay Jones wrote:\n>> Hmm, I was hoping that someone would say something like:\n>>\n>>    \"This test does not depend on the difference between the peg revision\n>> and the operative revision, because the history represented in the test\n>> repo is so simple that there *is* no difference, so Acked By: ... \"\n>\n> Unfortunately, I remain perpetually confused w.r.t peg revisions vs \"-r\"\n> and how it's handled differently between different SVN versions.\n\nI haven't followed this conversation, but I can explain what peg\nrevisions are. It used to be the only way to talk about a version of\na file or path was to use '-r REVNUM'. IIRC, what would happen is\nthat the url you provided would refer to the now current name of the\nfile, and Subversion would walk back in history to look up the\nspecified version of the file. However, that becomes a problem when\nthe file no longer exists, or has been renamed. It's compounded if\nthere is a new file with the same name in HEAD, because it would look\nup the wrong history. So peg revisions were introduced to say \"start\nlooking here @PEGREV and search forward or backwards for the version\nin REVNUM.\" So the difference is that old clients always looked at\nHEAD to start the search, whereas new clients will use PEGREV if\nspecified, and HEAD otherwise.\n\nThere is a pretty thorough discussion of it in the SVN book:\n \n\nHope that helps!\n\n-John\n"},{"id":"175408","messageId":"7v1uvkxt3n.fsf@alter.siamese.dyndns.org","threadId":"27829","inReplyTo":"20110913075726.GA15066@dcvr.yhbt.net","subject":"Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@' syntax","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-13T17:14:20Z","receivedAt":"2011-09-13T17:14:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks; will queue.\n"}]}