двунаправленная операция между репозиторием Subversion и Git (Bidirectional operation between a Subversion repository and Git)
Предостережение (Caveat)
For the sake of simplicity and interoperating with Subversion, it
is recommended that all git svn users clone, fetch and dcommit
directly from the SVN server, and avoid all git
clone/pull/merge/push operations between Git repositories and
branches. The recommended method of exchanging code between Git
branches and users is git format-patch and git am, or just
'dcommit'ing to the SVN repository.
Running git merge or git pull is NOT recommended on a branch you
plan to dcommit from because Subversion users cannot see any
merges you've made. Furthermore, if you merge or pull from a Git
branch that is a mirror of an SVN branch, dcommit may commit to
the wrong branch.
If you do merge, note the following rule: git svn dcommit will
attempt to commit on top of the SVN commit named in
git log --grep=^git-svn-id: --first-parent -1
You must therefore ensure that the most recent commit of the
branch you want to dcommit to is the first parent of the merge.
Chaos will ensue otherwise, especially if the first parent is an
older commit on the same SVN branch.
git clone does not clone branches under the refs/remotes/
hierarchy or any git svn metadata, or config. So repositories
created and managed with using git svn should use rsync for
cloning, if cloning is to be done at all.
Since dcommit uses rebase internally, any Git branches you git
push to before dcommit on will require forcing an overwrite of
the existing ref on the remote repository. This is generally
considered bad practice, see the git-push(1) documentation for
details.
Do not use the --amend option of git-commit(1) on a change you've
already dcommitted. It is considered bad practice to --amend
commits you've already pushed to a remote repository for other
users, and dcommit with SVN is analogous to that.
When cloning an SVN repository, if none of the options for
describing the repository layout is used (--trunk, --tags,
--branches, --stdlayout), git svn clone will create a Git
repository with completely linear history, where branches and
tags appear as separate directories in the working copy. While
this is the easiest way to get a copy of a complete repository,
for projects with many branches it will lead to a working copy
many times larger than just the trunk. Thus for projects using
the standard directory structure (trunk/branches/tags), it is
recommended to clone with option --stdlayout. If the project uses
a non-standard structure, and/or if branches and tags are not
required, it is easiest to only clone one directory (typically
trunk), without giving any repository layout options. If the full
history with branches and tags is required, the options --trunk /
--branches / --tags must be used.
When using multiple --branches or --tags, git svn does not
automatically handle name collisions (for example, if two
branches from different paths have the same name, or if a branch
and a tag have the same name). In these cases, use init to set up
your Git repository then, before your first fetch, edit the
$GIT_DIR/config file so that the branches and tags are associated
with different name spaces. For example:
branches = stable/*:refs/remotes/svn/stable/*
branches = debug/*:refs/remotes/svn/debug/*
