t9118 broken in current master, 9918285, git/git/v1.7.2-rc2

I've been busy with other projects and haven't attempted a full make & make test since f526d12, which did pass all the tests. Since the test name implies svn/git-svn breakage, I hoping the git-svn experts can find the problem.

This was on an amd64 Debian Squeeze system, up to date as of about 13:00 EDT today.

*** t9118-git-svn-funky-branch-names.sh ***
ok 1 - setup svnrepo
not ok - 2 test clone with funky branch names
#
# git svn clone -s "$svnrepo/pr ject" project &&
# cd project &&

#                       git rev-parse "refs/remotes/fun%20plugin" &&
#                       git rev-parse "refs/remotes/more%20fun%20plugin!" &&
#                       git rev-parse "refs/remotes/$scary_ref" &&
#                       git rev-parse "refs/remotes/%2Eleading_dot" &&
#                       git rev-parse "refs/remotes/trailing_dot%2E" &&
#                       git rev-parse "refs/remotes/trailing_dotlock%2Elock" &&
#                       git rev-parse "refs/remotes/not-a%40{0}reflog" &&

# cd ..
#
not ok - 3 test dcommit to funky branch
#

#               cd project &&
#               git reset --hard 'refs/remotes/more%20fun%20plugin!' &&
#               echo hello >> foo &&
#               git commit -m 'hello' -- foo &&
#               git svn dcommit &&
#               cd ..
#
not ok - 4 test dcommit to scary branch
#
#               cd project &&
#               git reset --hard "refs/remotes/$scary_ref" &&
#               echo urls are scary >> foo &&
#               git commit -m "eep" -- foo &&
#               git svn dcommit &&
#               cd ..
#
not ok - 5 test dcommit to trailing_dotlock branch
#
#               cd project &&
#               git reset --hard "refs/remotes/trailing_dotlock%2Elock" &&
#               echo who names branches like this anyway? >> foo &&
#               git commit -m "bar" -- foo &&
#               git svn dcommit &&
#               cd ..
#
# failed 4 among 5 test(s)

When test #2 fails, the cwd is project/, causing all the remaining tests in the same script to get confused and fail.

So in the spirit of v1.7.1.1~53^2~10 (t5550-http-fetch: Use subshell for repository operations, 2010-04-17), use a subshell for svn working copy operations. This way, the cwd will reliably return to the top of the trash directory and later tests can still be run when a command has failed.

---

Relates to an svn change from some point between 1.5.1 and 1.6.12. Not solved yet. See
<http://thread.gmane.org/gmane.comp.version-control.git/146498/focus=150549>.

Collateral damage. How about this patch?

 t/t9118-git-svn-funky-branch-names.sh |   46 ++++++++++++++++++---------------
 1 files changed, 25 insertions(+), 21 deletions(-)

index 7d7acc3..5dbea59 100755
@@ -34,42 +34,46 @@ test_expect_success 'setup svnrepo' '
 
 test_expect_success 'test clone with funky branch names' '
 	git svn clone -s "$svnrepo/pr ject" project &&
-	cd project &&
+	(
+		cd project &&
 		git rev-parse "refs/remotes/fun%20plugin" &&
 		git rev-parse "refs/remotes/more%20fun%20plugin!" &&
 		git rev-parse "refs/remotes/$scary_ref" &&
 		git rev-parse "refs/remotes/%2Eleading_dot" &&
 		git rev-parse "refs/remotes/trailing_dot%2E" &&
 		git rev-parse "refs/remotes/trailing_dotlock%2Elock" &&
-		git rev-parse "refs/remotes/not-a%40{0}reflog" &&
-	cd ..
+		git rev-parse "refs/remotes/not-a%40{0}reflog"
+	)
 	'
 
 test_expect_success 'test dcommit to funky branch' "
-	cd project &&
-	git reset --hard 'refs/remotes/more%20fun%20plugin!' &&
-	echo hello >> foo &&
-	git commit -m 'hello' -- foo &&
-	git svn dcommit &&
-	cd ..
+	(
+		cd project &&
+		git reset --hard 'refs/remotes/more%20fun%20plugin!' &&
+		echo hello >> foo &&
+		git commit -m 'hello' -- foo &&
+		git svn dcommit
+	)
 	"
 
 test_expect_success 'test dcommit to scary branch' '
-	cd project &&
-	git reset --hard "refs/remotes/$scary_ref" &&
-	echo urls are scary >> foo &&
-	git commit -m "eep" -- foo &&
-	git svn dcommit &&
-	cd ..
+	(
+		cd project &&
+		git reset --hard "refs/remotes/$scary_ref" &&
+		echo urls are scary >> foo &&
+		git commit -m "eep" -- foo &&
+		git svn dcommit
+	)
 	'
 
 test_expect_success 'test dcommit to trailing_dotlock branch' '
-	cd project &&
-	git reset --hard "refs/remotes/trailing_dotlock%2Elock" &&
-	echo who names branches like this anyway? >> foo &&
-	git commit -m "bar" -- foo &&
-	git svn dcommit &&
-	cd ..
+	(
+		cd project &&
+		git reset --hard "refs/remotes/trailing_dotlock%2Elock" &&
+		echo who names branches like this anyway? >> foo &&
+		git commit -m "bar" -- foo &&
+		git svn dcommit
+	)
 	'
 
 stop_httpd

1.7.2.rc1.527.gff41c3.dirty

Thanks.

Acked and pushed out to git://git.bogomips.org/git-svn
for Junio to pull:

Jonathan Nieder (1):
t9118 (git-svn): prevent early failure from taking down later tests

Michael J Gruber (1):
t9118: avoid PEG revision identifier in tests

Eric Wong

Good, it works as designed then. Thanks for checking.

I'm getting intermittent errors in t9115 instead. Running the full test suite with prove[1] gives:

./t9115-git-svn-dcommit-funky-renames.sh ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 9/10 subtests

Running the test separately gives:

 $ ./t9115-git-svn-dcommit-funky-renames.sh 
ok 1 - load repository with strange names
ok 2 - init and fetch repository
ok 3 - create file in existing ugly and empty dir
ok 4 - rename ugly file
ok 5 - rename pretty file
ok 6 - rename pretty file into ugly one
ok 7 - add a file with plus signs
ok 8 - clone the repository to test rebase
ok 9 - make a commit to test rebase
ok 10 - git svn rebase works inside a fresh-cloned repository
# passed all 10 test(s)
1..10

These may be unrelated, but thought I'd bring it up.

$ git describe HEAD
v1.7.2-rc2-191-gd2de19a

[1] prove -j 3 --state=hot,fresh,slow,save ./t[0-9]*.sh

Okay, but intermittent I mean that I had SVN_HTTPD_PORT defined in one place and not the other. It actually caused failures in tests 9115, 9120, 9142. Running tests in parallel appears to break the SVN httpd setup and teardown.

~~ Brian

If the test suite now fails if the tests are run in parallel then that's a new breakage. As of f526d12 "make -j4 test" was still passed on my system. The cut-n-paste in the email I sent last night was from a run without the -j4 make option so the problem is not just running the tests in parallel.