2006-07-06 11:14:16 +04:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
if test -n "$NO_SVN_TESTS"
|
2006-05-24 06:23:41 +04:00
|
|
|
then
|
2006-07-06 11:14:16 +04:00
|
|
|
test_expect_success 'skipping git-svn tests, NO_SVN_TESTS defined' :
|
|
|
|
|
test_done
|
|
|
|
|
exit
|
2006-05-24 06:23:41 +04:00
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
GIT_DIR=$PWD/.git
|
2006-05-24 12:22:07 +04:00
|
|
|
GIT_SVN_DIR=$GIT_DIR/svn/git-svn
|
git-svn: add support for Perl SVN::* libraries
This means we no longer have to deal with having bloated SVN
working copies around and we get a nice performance increase as
well because we don't have to exec the SVN binary and start a
new server connection each time.
Of course we have to manually manage memory with SVN::Pool
whenever we can, and hack around cases where SVN just eats
memory despite pools (I blame Perl, too). I would like to
keep memory usage as stable as possible during long fetch/commit
processes since I still use computers with only 256-512M RAM.
commit should always be faster with the SVN library code. The
SVN::Delta interface is leaky (or I'm not using it with pools
correctly), so I'm forking on every commit, but that doesn't
seem to hurt performance too much (at least on normal Unix/Linux
systems where fork() is pretty cheap).
fetch should be faster in most common cases, but probably not all.
fetches will be faster where client/server delta generation is
the bottleneck and not bandwidth. Of course, full-files are
generated server-side via deltas, too. Full files are always
transferred when they're updated, just like git-svnimport and
unlike command-line svn. I'm also hacking around memory leaks
(see comments) here by using some more forks.
I've tested fetch with http://, https://, file://, and svn://
repositories, so we should be reasonably covered in terms of
error handling for fetching.
Of course, we'll keep plain command-line svn compatibility as a
fallback for people running SVN 1.1 (I'm looking into library
support for 1.1.x SVN, too). If you want to force command-line
SVN usage, set GIT_SVN_NO_LIB=1 in your environment.
We also require two simultaneous connections (just like
git-svnimport), but this shouldn't be a problem for most
servers.
Less important commands:
show-ignore is slower because it requires repository
access, but -r/--revision <num> can be specified.
graft-branches may use more memory, but it's a
short-term process and is funky-filename-safe.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
2006-06-13 02:23:48 +04:00
|
|
|
SVN_TREE=$GIT_SVN_DIR/svn-tree
|
2006-05-24 06:23:41 +04:00
|
|
|
|
2006-07-07 14:17:16 +04:00
|
|
|
perl -e 'use SVN::Core' >/dev/null 2>&1
|
|
|
|
|
if test $? -ne 0
|
|
|
|
|
then
|
|
|
|
|
echo 'Perl SVN libraries not found, tests requiring those will be skipped'
|
|
|
|
|
GIT_SVN_NO_LIB=1
|
|
|
|
|
fi
|
|
|
|
|
|
2006-05-24 06:23:41 +04:00
|
|
|
svnadmin >/dev/null 2>&1
|
2006-07-07 14:17:16 +04:00
|
|
|
if test $? -ne 1
|
2006-05-24 06:23:41 +04:00
|
|
|
then
|
2006-07-06 11:14:16 +04:00
|
|
|
test_expect_success 'skipping git-svn tests, svnadmin not found' :
|
2006-05-24 06:23:41 +04:00
|
|
|
test_done
|
|
|
|
|
exit
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
svn >/dev/null 2>&1
|
2006-07-07 14:17:16 +04:00
|
|
|
if test $? -ne 1
|
2006-05-24 06:23:41 +04:00
|
|
|
then
|
2006-07-06 11:14:16 +04:00
|
|
|
test_expect_success 'skipping git-svn tests, svn not found' :
|
2006-05-24 06:23:41 +04:00
|
|
|
test_done
|
|
|
|
|
exit
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
svnrepo=$PWD/svnrepo
|
|
|
|
|
|
|
|
|
|
set -e
|
|
|
|
|
|
git-svn: SVN 1.1.x library compatibility
Tested on a plain Ubuntu Hoary installation
using subversion 1.1.1-2ubuntu3
1.1.x issues I had to deal with:
* Avoid the noisy command-line client compatibility check if we
use the libraries.
* get_log() arguments differ (now using a nice wrapper from
Junio's suggestion)
* get_file() is picky about what kind of file handles it gets,
so I ended up redirecting STDOUT. I'm probably overflushing
my file handles, but that's the safest thing to do...
* BDB kept segfaulting on me during tests, so svnadmin will use FSFS
whenever we can.
* If somebody used an expanded CVS $Id$ line inside a file, then
propsetting it to use svn:keywords will cause the original CVS
$Id$ to be retained when asked for the original file. As far as
I can see, this is a server-side issue. We won't care in the
test anymore, as long as it's not expanded by SVN, a static
CVS $Id$ line is fine.
While we're at making ourselves more compatible, avoid grep
along with the -q flag, which is GNU-specific. (grep avoidance
tip from Junio, too)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-28 14:07:14 +04:00
|
|
|
if svnadmin create --help | grep fs-type >/dev/null
|
|
|
|
|
then
|
|
|
|
|
svnadmin create --fs-type fsfs "$svnrepo"
|
|
|
|
|
else
|
|
|
|
|
svnadmin create "$svnrepo"
|
|
|
|
|
fi
|
|
|
|
|
|
2006-05-24 06:23:41 +04:00
|
|
|
svnrepo="file://$svnrepo/test-git-svn"
|
|
|
|
|
|
|
|
|
|
|
