[PATCH 0/3] git-svn: pass tests on svn trunk

While svn trunk is a dubious target to integrate with, perhaps these
patches will prove useful to include anyway.

Tested against svn 1.4.2 and svn trunk r26724

Older svn clients did not raise a 'transaction out of date' error here, but
trunk does - so 'svn up'.

Signed-off-by: Sam Vilain <redacted>
---
 t/t9101-git-svn-props.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index 622ea1c..5aac644 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh

@@ -140,6 +140,7 @@ test_expect_success 'test show-ignore' "
 	cd test_wc &&
 	mkdir -p deeply/nested/directory &&
 	svn add deeply &&
+	svn up &&
 	svn propset -R svn:ignore 'no-such-file*' .
 	svn commit -m 'propset svn:ignore'
 	cd .. &&

-- 
1.5.2.4

Previously, if you passed a revision and a path to svn, 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.  The old syntax is selected with new
syntax PATH@REV.  This new syntax is not supported by the old tools, so we
have to try both in turn.

Signed-off-by: Sam Vilain <redacted>
---
 t/t9104-git-svn-follow-parent.sh |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 9eab945..7ba7630 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh

@@ -51,8 +51,10 @@ test_expect_success 'init and fetch from one svn-remote' "
         "
 
 test_expect_success 'follow deleted parent' "
-        svn cp -m 'resurrecting trunk as junk' \
-               -r2 $svnrepo/trunk $svnrepo/junk &&
+        (svn cp -m 'resurrecting trunk as junk' \
+               $svnrepo/trunk@2 $svnrepo/junk ||
+         svn cp -m 'resurrecting trunk as junk' \
+               -r2 $svnrepo/trunk $svnrepo/junk) &&
         git config --add svn-remote.svn.fetch \
           junk:refs/remotes/svn/junk &&
         git-svn fetch -i svn/thunk &&

-- 
1.5.2.4

The 'svn mv -m "rename to thunk"' was a local operation, therefore not
needing a commit message, it was silently ignored.  Newer svn clients will
instead raise an error.

Signed-off-by: Sam Vilain <redacted>
---
 t/t9104-git-svn-follow-parent.sh |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index d8f9cab..9eab945 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh

@@ -19,8 +19,7 @@ test_expect_success 'initialize repo' "
 	poke trunk/readme &&
 	svn commit -m 'another commit' &&
 	svn up &&
-	svn mv -m 'rename to thunk' trunk thunk &&
-	svn up &&
+	svn mv trunk thunk &&
 	echo goodbye >> thunk/readme &&
 	poke thunk/readme &&
 	svn commit -m 'bye now' &&

-- 
1.5.2.4

Sam Vilain wrote:

Previously, if you passed a revision and a path to svn, 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.  The old syntax is selected with new
syntax PATH@REV.  This new syntax is not supported by the old tools, so we
have to try both in turn.

Blast, this analysis is wrong.  Hold off, I'll see what's really going
on and re-submit.

Sam.

Sam Vilain wrote:

Sam Vilain wrote:

quoted

Previously, if you passed a revision and a path to svn, 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.  The old syntax is selected with new
syntax PATH@REV.  This new syntax is not supported by the old tools, so we
have to try both in turn.

Blast, this analysis is wrong.  Hold off, I'll see what's really going
on and re-submit.

ok, figured it out :)

I was close!  I was just thrown off by 'svn ls PATH@REV'

The patch is the same, just the description has changed.

Subject: [PATCH] git-svn: handle changed svn cp 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.
---
 t/t9104-git-svn-follow-parent.sh |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 9eab945..7ba7630 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh

@@ -51,8 +51,10 @@ test_expect_success 'init and fetch from one svn-remote' "
         "
 
 test_expect_success 'follow deleted parent' "
-        svn cp -m 'resurrecting trunk as junk' \
-               -r2 $svnrepo/trunk $svnrepo/junk &&
+        (svn cp -m 'resurrecting trunk as junk' \
+               $svnrepo/trunk@2 $svnrepo/junk ||
+         svn cp -m 'resurrecting trunk as junk' \
+               -r2 $svnrepo/trunk $svnrepo/junk) &&
         git config --add svn-remote.svn.fetch \
           junk:refs/remotes/svn/junk &&
         git-svn fetch -i svn/thunk &&

-- 
1.5.3.2.3.g2f2dcc-dirty

Sam Vilain [off-list ref] wrote:

Sam Vilain wrote:

quoted

Sam Vilain wrote:

quoted

Previously, if you passed a revision and a path to svn, 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.  The old syntax is selected with new
syntax PATH@REV.  This new syntax is not supported by the old tools, so we
have to try both in turn.

Blast, this analysis is wrong.  Hold off, I'll see what's really going
on and re-submit.

ok, figured it out :)

I was close!  I was just thrown off by 'svn ls PATH@REV'

The patch is the same, just the description has changed.

Subject: [PATCH] git-svn: handle changed svn cp 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.

The @REV and -rREV distinction/ambiguity has always confused me in svn,
too.  It always seems that it needed to be one way sometimes, the other
way at other times, and even _both_ at other times...

-- 
Eric Wong

Sam Vilain [off-list ref] wrote:

While svn trunk is a dubious target to integrate with, perhaps these
patches will prove useful to include anyway.

Tested against svn 1.4.2 and svn trunk r26724

Fine by me, as what's in trunk will likely be in a released version some
day and I'm glad that people are already testing git-svn against it.

This series Acked-by: Eric Wong [off-list ref]

-- 
Eric Wong

On 2007-09-21 01:23:48 -0700, Eric Wong wrote:

The @REV and -rREV distinction/ambiguity has always confused me in svn,
too.  It always seems that it needed to be one way sometimes, the other
way at other times, and even _both_ at other times...

-rREV specifies the operative revision, and @REV specifies the peg
revision. See the clear but dreadfully long explanation here:

  http://svnbook.red-bean.com/en/1.4/svn.advanced.pegrevs.html

In short, it's a way to manage the complexity that comes from
considering files (and directories!) to have an identity that is
preserved across copies and renames.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle