should be the same as above.
------------------------------------------------------------------------

The initial 'git svn clone' can be quite time-consuming
(especially for large Subversion repositories). If multiple
people (or one person with multiple machines) want to use
'git svn' to interact with the same Subversion repository, you can
do the initial 'git svn clone' to a repository on a server and
have each person clone that repository with 'git clone':

------------------------------------------------------------------------
# Do the initial import on a server
	ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
# Clone locally - make sure the refs/remotes/ space matches the server
	mkdir project
	cd project
	git init
	git remote add origin server:/pub/project
	git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
	git fetch
# Prevent fetch/pull from remote Git server in the future,
# we only want to use git svn for future updates
	git config --remove-section remote.origin
# Create a local branch from one of the branches just fetched
	git checkout -b master FETCH_HEAD
# Initialize 'git svn' locally (be sure to use the same URL and
# --stdlayout/-T/-b/-t/--prefix options as were used on server)
	git svn init http://svn.example.com/project [options...]
# Pull the latest changes from Subversion
	git svn rebase
------------------------------------------------------------------------

REBASE VS. PULL/MERGE
---------------------
Prefer to use 'git svn rebase' or 'git rebase', rather than
'git pull' or 'git merge' to synchronize unintegrated commits with a 'git svn'
branch. Doing so will keep the history of unintegrated commits linear with
respect to the upstream SVN repository and allow the use of the preferred
'git svn dcommit' subcommand to push unintegrated commits back into SVN.

Originally, 'git svn' recommended that developers pulled or merged from
the 'git svn' branch.  This was because the author favored
`git svn set-tree B` to commit a single head rather than the
`git svn set-tree A..B` notation to commit multiple commits. Use of
'git pull' or 'git merge' with `git svn set-tree A..B` will cause non-linear
history to be flattened when committing into SVN and this can lead to merge
commits unexpectedly reversing previous commits in SVN.

MERGE TRACKING
--------------
While 'git svn' can track
copy history (including branches and tags) for repositories adopting a
standard layout, it cannot yet represent merge history that happened
inside git back upstream to SVN users.  Therefore it is advised that
users keep history as linear as possible inside Git to ease
compatibility with SVN (see the CAVEATS section below).

HANDLING OF SVN BRANCHES
------------------------
If 'git svn' is configured to fetch branches (and --follow-branches
is in effect), it sometimes creates multiple Git branches for one
SVN branch, where the additional branches have names of the form
'branchname@nnn' (with nnn an SVN revision number).  These additional
branches are created if 'git svn' cannot find a parent commit for the
first commit in an SVN branch, to connect the branch to the history of
the other branches.

Normally, the first commit in an SVN branch consists
of a copy operation. 'git svn' will read this commit to get the SVN
revision the branch was created from. It will then try to find the
Git commit that corresponds to this SVN revision, and use that as the
parent of the branch. However, it is possible that there is no suitable
Git commit to serve as parent.  This will happen, among other reasons,
if the SVN branch is a copy of a revision that was not fetched by 'git
svn' (e.g. because it is an old revision that was skipped with
`--revision`), or if in SVN a directory was copied that is not tracked
by 'git svn' (such as a branch that is not tracked at all, or a
subdirectory of a tracked branch). In these cases, 'git svn' will still
create a Git branch, but instead of using an existing Git