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@xxxxxxxxxxxxxxxxxxx> --- 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html