As reported by Matthieu Moy, this is causing svnserve to
terminate connections (because it segfaults) segfault.
This test is disabled by default and can be enabled by setting
SVNSERVE_PORT to an unbound (for 127.0.0.1) TCP port in the
environment (in addition to SVN_TESTS=1). I'm not comfortable
with having a test start a daemon by default and take up a port
that could potentially stay running if the test failed.
Signed-off-by: Eric Wong <normalperson@xxxxxxxx>
---
t/t9113-git-svn-dcommit-new-file.sh | 40 +++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
create mode 100755 t/t9113-git-svn-dcommit-new-file.sh
diff --git a/t/t9113-git-svn-dcommit-new-file.sh b/t/t9113-git-svn-dcommit-new-file.sh
new file mode 100755
index 0000000..9ef0db9
--- /dev/null
+++ b/t/t9113-git-svn-dcommit-new-file.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Eric Wong
+#
+
+# Don't run this test by default unless the user really wants it
+# I don't like the idea of taking a port and possibly leaving a
+# daemon running on a users system if the test fails.
+# Not all git users will need to interact with SVN.
+test -z "$SVNSERVE_PORT" && exit 0
+
+test_description='git-svn dcommit new files over svn:// test'
+
+. ./lib-git-svn.sh
+
+start_svnserve () {
+ svnserve --listen-port $SVNSERVE_PORT \
+ --root $rawsvnrepo \
+ --listen-once \
+ --listen-host 127.0.0.1 &
+}
+
+test_expect_success 'start tracking an empty repo' "
+ svn mkdir -m 'empty dir' $svnrepo/empty-dir &&
+ echo anon-access = write >> $rawsvnrepo/conf/svnserve.conf &&
+ start_svnserve &&
+ git svn init svn://127.0.0.1:$SVNSERVE_PORT &&
+ git svn fetch
+ "
+
+test_expect_success 'create files in new directory with dcommit' "
+ mkdir git-new-dir &&
+ echo hello > git-new-dir/world &&
+ git update-index --add git-new-dir/world &&
+ git commit -m hello &&
+ start_svnserve &&
+ git svn dcommit
+ "
+
+test_done
--
1.5.2.1.243.gbe00
-
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
