Some of the recent changes and shortcuts to the tests broke
things for people using older versions of svn:

t9104-git-svn-follow-parent.sh:
  v1.2.3 (from SuSE 10.0 as reported by riddochc on #git
  (thanks!)) required an extra 'svn up'.  I was also able to
  reproduce this with v1.1.4 (Debian Sarge).

lib-git-svn.sh:
  SVN::Repos bindings in versions up to and including 1.1.4
  (Sarge again) do not pass fs-config options to the underlying
  library.  BerkeleyDB repositories also seem completely broken
  on all my Sarge machines; so not using FSFS does not seem to
  be an option for most people.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We require the libraries now, so we can create repositories
using them (and save some executable load time while we're at
it).
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Using the command-line client was great for prototyping and
getting something working quickly.  Eventually I found time
to study the library documentation and add support for using
the libraries which are much faster and more flexible when
it comes to supporting new features.

Note that we require version 1.1 of the SVN libraries, whereas
we supported the command-line svn client down to version 1.0.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* Enable test for delta transfers in full-svn-test.

* Run tests against the root of the repository so we won't have
  to revisit 308906fa and
  efe4631d again.
  The graft-branches test still runs as before.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Check for SVN::Core so test 910[45] don't fail if the user
doesn't have those installed.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Allow NO_SVN_TESTS to be defined to skip git-svn tests.  These
tests are time-consuming due to SVN being slow, and even more so
if SVN Perl libraries are not available.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NEric Wong <normalperson@yhbt.net>

Since GIT_SVN_ID usage is probably going to become more
widespread <evil grin>, we won't run the chance of somebody
having a GIT_SVN_ID name that conflicts with one of the default
directories that already exist in $GIT_DIR (branches/tags).
Signed-off-by: NEric Wong <normalperson@yhbt.net>

Unlike my earlier test patch, this also checks svn:eol-style and
makes sure it's applied to working copy updates.  This is
definitely more correct than my original attempt at killing
keyword expansions, but I still haven't tested it enough to
know.  Feedback would be much appreciated.

Also changed assert_svn_wc_clean() to only work on the svn
working copy.  This requires a separate call to assert_tree() to
check wc integrity against git in preparation for another change
I'm planning.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>