kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Eric Wong	42d328701d	git-svn: make the $GIT_DIR/svn/*/revs directory obsolete This is a very intrusive change, so I've beefed up the tests significantly. Added 'full-test' a target to the Makefile, to test different possible configurations. This is intended for maintainers only. Users should only be concerned with 'test' succeeding. We now have a very simple custom database format for handling mapping of svn revisions => git commits. Of course, we're not really using it yet, either. Also disabled automatic branch-finding on new trees for now. It's too easily broken. revisions_eq() function should be helpful for branch detection. Also removed an extra assertion in fetch_cmd() that wasn't correctly done. This bug was found by full-test. Signed-off-by: Eric Wong <normalperson@yhbt.net>	19 years ago
Eric Wong	a5e0cedc0a	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>	19 years ago
Eric Wong	7a97de4e19	git-svn: add UTF-8 message test Signed-off-by: Eric Wong <normalperson@yhbt.net>	19 years ago
Eric Wong	c7162c1db6	git-svn: t0000: add -f flag to checkout Some changes to the latest git.git made this test croak. So we'll always just force everything when using a new branch. Signed-off-by: Eric Wong <normalperson@yhbt.net>	19 years ago
Eric Wong	36f5b1f0c8	git-svn: ignore expansion of svn:keywords 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: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Eric Wong	2beb3cdd18	contrib/git-svn: use refs/remotes/git-svn instead of git-svn-HEAD After reading a lengthy discussion on the list, I've come to the conclusion that creating a 'remotes' directory in refs isn't such a bad idea. You can still branch from it by specifying remotes/git-svn (not needing the leading 'refs/'), and the documentation has been updated to reflect that. The 'git-svn' part of the ref can of course be set to whatever you want by using the GIT_SVN_ID environment variable, as before. I'm using refs/remotes/git-svn, and not going with something like refs/remotes/git-svn/HEAD as it's redundant for Subversion where there's zero distinction between branches and directories. Run git-svn rebuild --upgrade to upgrade your repository to use the new head. git-svn-HEAD must be manually deleted for safety reasons. Side note: if you ever (and I hope you never) want to run git-update-refs on a 'remotes/' ref, make sure you have the 'refs/' prefix as you don't want to be clobbering your 'remotes/' in $GIT_DIR (where remote URLs are stored). Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Eric Wong	96a40b27c9	contrib/git-svn: add Makefile, test, and associated ignores Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago