Git-Svn-Bridge

Hi,

we would like to use a Git-Svn-Bridge as it is described in Jon Loeliger's book. However there are some open questions:

We have the bridge repository and the bare repository created. 

a) Are the developers supposed to work on a branch that follows master from the bare repository or on a branch that follows svn/trunk on the master? I assume they follow the master.

b) How do we get changes from the bare repository to the bridge repository? Should there be a new branch for the changes or should one use master from the bridge?

c) How do we get changes from subversion to the bare repository?

d) Are the changes from subversion applied to the bare repository master or only to the svn/* branches?

Thanks Christoph

I would like to add a +1 on this topic.

There are very few "official" resources or de-facto recipes on how to set up a git-svn bridge.

According to the 2010 survey [1], roughly 20% use git-svn in some way. A subset of these are probably very interested in a git-svn-bridge setup that works.

I've experimented with my own "hybrid bridge" setup [2], but I've yet to hear whether it's wrong or can be done better. Someone on #git claimed it was more complicated that it had to be, but as far as I've heard, the setup in Loeliger's book is even worse [3] (no offense to his book though, I haven't read it but heard it's great).

I've roamed through this mailing list, StackOverflow, and generally googled all over, but I haven't found any *really* good setups. It's not mentioned in the GitSVN migration guide [4]. With the amount of people still using git-svn, I would've thought this topic would get some more attention.

Some say that creating a centralized bridge is generally bad idea, and it's better for all to just individually use git-svn as an SVN-client directly. But I'm sure if I had advocated this at my company, checkout/update performance wouldn't impress many, and I would still be the only git-user. Thanks to the git-svn bridge, we are now a handful Git-users, using Git for builds in Hudson, and steadily gaining traction.

So, to shape it in form of a question: What is the optimal git-svn bridge setup?

Thanks,

-Thomas

[1] https://git.wiki.kernel.org/index.php/GitSurvey2010 [2] http://www.tfnico.com/presentations/git-and-subversion [3] http://blog.emmanuelbernard.com/2010/05/git-how-my-life-has-improved-since-last-month-when-i-used-svn/comment-page-1/#comment-2248 [4] https://git.wiki.kernel.org/index.php/SvnMigration

2010/11/17 Christoph Bartoschek <bartoschek@gmx.de>:

Thomas Ferris Nicolaisen wrote:

...

...

I see the following advantages of the Loeliger setup:

- The master branch on the bare repository reflects the whole history. The 
branches and merges the git users perform are visible in this branch.

- The git users do not need to know about subversion.

This is how I currently understand the setup:

A.1. Clone the subversion repository to a fetching git repository:

git svn clone -s --prefix=svn/ <SVN-URL> fetch.git

A.2. Fix master to check to the correct commit:

git reset --hard svn/trunk

A.3. Create a local branch for each subversion branch to follow:

git branch branch_A svn/branch_A

A.4. Create a bare repository that is used as depot for git:

git init --bare bare.git

A.5. Push the branches to the depot:

git push --all ../bare.git git push ../bare.git 'refs/remotes/svn/*:refs/heads/svn/*

Now the setup is done and the git users can start to clone the depot and continue to work. The convention is that the svn/* branches always only reflect the subversion history. One does not directly work on them. Work is done on master and the branches that have been created locally.

If there are no updates to the bare repository but changes to subversion then one can update the bare repository with:

B.1. Go to the fetch repository and get the newest svn data:

git svn fetch

B.2. Merge the new data to each branch that tracks a svn branch:

git checkout master git merge svn/trunk git checkout branch_A git merge svn/branch_A

B.3. Push the new data to the bare repository:

git push -all ../bare.git git push ../bare.git 'refs/remotes/svn/*:refs/heads/svn/*'

Are there shortcuts to get the commands in B.2 and B.3 in a single one?

Now changes are commited to master on the bare repository and one wants to push them to the subversion server. If there are changes on the subversion side also fetch them:

C.1: Go to the fetch repository and pull the changes from the bare repository:

git checkout master git pull ../bare.git master git checkout branch_A git pull ../bare.git branch_A

Is there a shortcut?

C.2: Fetch changes from svn:

git svn fetch

C.3: Create detached heads from the svn branches one follows, merge the changes from the git branches and dcommit them:

git checkout svn/trunk git merge --no-ff --log master git svn dcommit

Same for branch_A.

C.4: Merge the newly created subversion commit to the git branches:

git checkout master git merge svn/trunk git checkout branch_A git merge svn/branch_A

C.5: Push the new commits to the bare repository:

git push --all ../bare.git git push ../bare.git 'refs/remotes/svn/*:refs/heads/svn/*'

This is how I understand the setup. Do you see any mistakes or ways to improve it?

Thanks Christoph