- 14 1月, 2007 1 次提交
-
-
由 Eric Wong 提交于
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>
-
- 01 1月, 2007 1 次提交
-
-
由 Eric Wong 提交于
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>
-
- 16 12月, 2006 1 次提交
-
-
由 Eric Wong 提交于
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>
-
- 28 11月, 2006 1 次提交
-
-
由 Eric Wong 提交于
* 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>
-
- 07 7月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
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>
-
由 Eric Wong 提交于
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>
-
- 28 6月, 2006 1 次提交
-
-
由 Eric Wong 提交于
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>
-
- 16 6月, 2006 2 次提交
-
-
由 Eric Wong 提交于
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>
-
由 Eric Wong 提交于
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>
-
- 24 5月, 2006 1 次提交
-
-
由 Eric Wong 提交于
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>
-