git-svn: migrate out of contrib

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

1 files changed, 319 insertions, 0 deletions

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
new file mode 100644
index 0000000000..f7d3de48f0
--- /dev/null
+++ b/Documentation/git-svn.txt
@@ -0,0 +1,319 @@
+git-svn(1)
+==========
+
+NAME
+----
+git-svn - bidirectional operation between a single Subversion branch and git
+
+SYNOPSIS
+--------
+'git-svn' <command> [options] [arguments]
+
+DESCRIPTION
+-----------
+git-svn is a simple conduit for changesets between a single Subversion
+branch and git.
+
+git-svn is not to be confused with git-svnimport.  The were designed
+with very different goals in mind.
+
+git-svn is designed for an individual developer who wants a
+bidirectional flow of changesets between a single branch in Subversion
+and an arbitrary number of branches in git.  git-svnimport is designed
+for read-only operation on repositories that match a particular layout
+(albeit the recommended one by SVN developers).
+
+For importing svn, git-svnimport is potentially more powerful when
+operating on repositories organized under the recommended
+trunk/branch/tags structure, and should be faster, too.
+
+git-svn mostly ignores the very limited view of branching that
+Subversion has.  This allows git-svn to be much easier to use,
+especially on repositories that are not organized in a manner that
+git-svnimport is designed for.
+
+COMMANDS
+--------
+init::
+	Creates an empty git repository with additional metadata
+	directories for git-svn.  The Subversion URL must be specified
+	as a command-line argument.
+
+fetch::
+	Fetch unfetched revisions from the Subversion URL we are
+	tracking.  refs/remotes/git-svn will be updated to the
+	latest revision.
+
+	Note: You should never attempt to modify the remotes/git-svn
+	branch outside of git-svn.  Instead, create a branch from
+	remotes/git-svn and work on that branch.  Use the 'commit'
+	command (see below) to write git commits back to
+	remotes/git-svn.
+
+	See 'Additional Fetch Arguments' if you are interested in
+	manually joining branches on commit.
+
+commit::
+	Commit specified commit or tree objects to SVN.  This relies on
+	your imported fetch data being up-to-date.  This makes
+	absolutely no attempts to do patching when committing to SVN, it
+	simply overwrites files with those specified in the tree or
+	commit.  All merging is assumed to have taken place
+	independently of git-svn functions.
+
+rebuild::
+	Not a part of daily usage, but this is a useful command if
+	you've just cloned a repository (using git-clone) that was
+	tracked with git-svn.  Unfortunately, git-clone does not clone
+	git-svn metadata and the svn working tree that git-svn uses for
+	its operations.  This rebuilds the metadata so git-svn can
+	resume fetch operations.  A Subversion URL may be optionally
+	specified at the command-line if the directory/repository you're
+	tracking has moved or changed protocols.
+
+show-ignore::
+	Recursively finds and lists the svn:ignore property on
+	directories.  The output is suitable for appending to
+	the $GIT_DIR/info/exclude file.
+
+OPTIONS
+-------
+-r <ARG>::
+--revision <ARG>::
+	Only used with the 'fetch' command.
+
+	Takes any valid -r<argument> svn would accept and passes it
+	directly to svn. -r<ARG1>:<ARG2> ranges and "{" DATE "}" syntax
+	is also supported.  This is passed directly to svn, see svn
+	documentation for more details.
+
+	This can allow you to make partial mirrors when running fetch.
+
+-::
+--stdin::
+	Only used with the 'commit' command.
+
+	Read a list of commits from stdin and commit them in reverse
+	order.  Only the leading sha1 is read from each line, so
+	git-rev-list --pretty=oneline output can be used.
+
+--rmdir::
+	Only used with the 'commit' command.
+
+	Remove directories from the SVN tree if there are no files left
+	behind.  SVN can version empty directories, and they are not
+	removed by default if there are no files left in them.  git
+	cannot version empty directories.  Enabling this flag will make
+	the commit to SVN act like git.
+
+	repo-config key: svn.rmdir
+
+-e::
+--edit::
+	Only used with the 'commit' command.
+
+	Edit the commit message before committing to SVN.  This is off by
+	default for objects that are commits, and forced on when committing
+	tree objects.
+
+	repo-config key: svn.edit
+
+-l<num>::
+--find-copies-harder::
+	Both of these are only used with the 'commit' command.
+
+	They are both passed directly to git-diff-tree see
+	git-diff-tree(1) for more information.
+
+	repo-config key: svn.l
+	repo-config key: svn.findcopiesharder
+
+-A<filename>::
+--authors-file=<filename>::
+
+	Syntax is compatible with the files used by git-svnimport and
+	git-cvsimport:
+
+------------------------------------------------------------------------
+loginname = Joe User <user@example.com>
+------------------------------------------------------------------------
+
+	If this option is specified and git-svn encounters an SVN
+	committer name that does not exist in the authors-file, git-svn
+	will abort operation. The user will then have to add the
+	appropriate entry.  Re-running the previous git-svn command
+	after the authors-file is modified should continue operation.
+
+	repo-config key: svn.authors-file
+
+ADVANCED OPTIONS
+----------------
+-b<refname>::
+--branch <refname>::
+	Used with 'fetch' or 'commit'.
+
+	This can be used to join arbitrary git branches to remotes/git-svn
+	on new commits where the tree object is equivalent.
+
+	When used with different GIT_SVN_ID values, tags and branches in
+	SVN can be tracked this way, as can some merges where the heads
+	end up having completely equivalent content.  This can even be
+	used to track branches across multiple SVN _repositories_.
+
+	This option may be specified multiple times, once for each
+	branch.
+
+	repo-config key: svn.branch
+
+-i<GIT_SVN_ID>::
+--id <GIT_SVN_ID>::
+	This sets GIT_SVN_ID (instead of using the environment).  See
+	the section on "Tracking Multiple Repositories or Branches" for
+	more information on using GIT_SVN_ID.
+
+COMPATIBILITY OPTIONS
+---------------------
+--upgrade::
+	Only used with the 'rebuild' command.
+
+	Run this if you used an old version of git-svn that used
+	"git-svn-HEAD" instead of "remotes/git-svn" as the branch
+	for tracking the remote.
+
+--no-ignore-externals::
+	Only used with the 'fetch' and 'rebuild' command.
+
+	By default, git-svn passes --ignore-externals to svn to avoid
+	fetching svn:external trees into git.  Pass this flag to enable
+	externals tracking directly via git.
+
+	Versions of svn that do not support --ignore-externals are
+	automatically detected and this flag will be automatically
+	enabled for them.
+
+	Otherwise, do not enable this flag unless you know what you're
+	doing.
+
+	repo-config key: svn.noignoreexternals
+
+Basic Examples
+~~~~~~~~~~~~~~
+
+Tracking and contributing to an Subversion managed-project:
+
+------------------------------------------------------------------------
+# Initialize a tree (like git init-db):
+	git-svn init http://svn.foo.org/project/trunk
+# Fetch remote revisions:
+	git-svn fetch
+# Create your own branch to hack on:
+	git checkout -b my-branch remotes/git-svn
+# Commit only the git commits you want to SVN:
+	git-svn commit <tree-ish> [<tree-ish_2> ...]
+# Commit all the git commits from my-branch that don't exist in SVN:
+	git-svn commit remotes/git-svn..my-branch
+# Something is committed to SVN, pull the latest into your branch:
+	git-svn fetch && git pull . remotes/git-svn
+# Append svn:ignore settings to the default git exclude file:
+	git-svn show-ignore >> .git/info/exclude
+------------------------------------------------------------------------
+
+DESIGN PHILOSOPHY
+-----------------
+Merge tracking in Subversion is lacking and doing branched development
+with Subversion is cumbersome as a result.  git-svn completely forgoes
+any automated merge/branch tracking on the Subversion side and leaves it
+entirely up to the user on the git side.  It's simply not worth it to do
+a useful translation when the the original signal is weak.
+
+TRACKING MULTIPLE REPOSITORIES OR BRANCHES
+------------------------------------------
+This is for advanced users, most users should ignore this section.
+
+Because git-svn does not care about relationships between different
+branches or directories in a Subversion repository, git-svn has a simple
+hack to allow it to track an arbitrary number of related _or_ unrelated
+SVN repositories via one git repository.  Simply set the GIT_SVN_ID
+environment variable to a name other other than "git-svn" (the default)
+and git-svn will ignore the contents of the $GIT_DIR/git-svn directory
+and instead do all of its work in $GIT_DIR/$GIT_SVN_ID for that
+invocation.  The interface branch will be remotes/$GIT_SVN_ID, instead of
+remotes/git-svn.  Any remotes/$GIT_SVN_ID branch should never be modified
+by the user outside of git-svn commands.
+
+ADDITIONAL FETCH ARGUMENTS
+--------------------------
+This is for advanced users, most users should ignore this section.
+
+Unfetched SVN revisions may be imported as children of existing commits
+by specifying additional arguments to 'fetch'.  Additional parents may
+optionally be specified in the form of sha1 hex sums at the
+command-line.  Unfetched SVN revisions may also be tied to particular
+git commits with the following syntax:
+
+	svn_revision_number=git_commit_sha1
+
+This allows you to tie unfetched SVN revision 375 to your current HEAD::
+
+	`git-svn fetch 375=$(git-rev-parse HEAD)`
+
+Advanced Example: Tracking a Reorganized Repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+If you're tracking a directory that has moved, or otherwise been
+branched or tagged off of another directory in the repository and you
+care about the full history of the project, then you can read this
+section.
+
+This is how Yann Dirson tracked the trunk of the ufoai directory when
+the /trunk directory of his repository was moved to /ufoai/trunk and
+he needed to continue tracking /ufoai/trunk where /trunk left off.
+
+------------------------------------------------------------------------
+	# This log message shows when the repository was reorganized:
+	r166 | ydirson | 2006-03-02 01:36:55 +0100 (Thu, 02 Mar 2006) | 1 line
+	Changed paths:
+	   D /trunk
+	   A /ufoai/trunk (from /trunk:165)
+
+	# First we start tracking the old revisions:
+	GIT_SVN_ID=git-oldsvn git-svn init \
+			https://svn.sourceforge.net/svnroot/ufoai/trunk
+	GIT_SVN_ID=git-oldsvn git-svn fetch -r1:165
+
+	# And now, we continue tracking the new revisions:
+	GIT_SVN_ID=git-newsvn git-svn init \
+	      https://svn.sourceforge.net/svnroot/ufoai/ufoai/trunk
+	GIT_SVN_ID=git-newsvn git-svn fetch \
+	      166=`git-rev-parse refs/remotes/git-oldsvn`
+------------------------------------------------------------------------
+
+BUGS
+----
+If somebody commits a conflicting changeset to SVN at a bad moment
+(right before you commit) causing a conflict and your commit to fail,
+your svn working tree ($GIT_DIR/git-svn/tree) may be dirtied.  The
+easiest thing to do is probably just to rm -rf $GIT_DIR/git-svn/tree and
+run 'rebuild'.
+
+We ignore all SVN properties except svn:executable.  Too difficult to
+map them since we rely heavily on git write-tree being _exactly_ the
+same on both the SVN and git working trees and I prefer not to clutter
+working trees with metadata files.
+
+svn:keywords can't be ignored in Subversion (at least I don't know of
+a way to ignore them).
+
+Renamed and copied directories are not detected by git and hence not
+tracked when committing to SVN.  I do not plan on adding support for
+this as it's quite difficult and time-consuming to get working for all
+the possible corner cases (git doesn't do it, either).  Renamed and
+copied files are fully supported if they're similar enough for git to
+detect them.
+
+Author
+------
+Written by Eric Wong <normalperson@yhbt.net>.
+
+Documentation
+-------------
+Written by Eric Wong <normalperson@yhbt.net>.