git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Git-Svn-Bridge

From
CBChristoph Bartoschek <bartoschek@gmx.de>
Date
Nov 21, 2010, 20:24 UTC
Message-ID
<dpbor7-rtk.ln1@homer.bruehl.pontohonk.de>
In-Reply-To
<AANLkTimH=iv5y5OdBXnVM=EVY2+FvY7dTgnLc4pZSkWP@mail.gmail.com>
Thomas Ferris Nicolaisen wrote:
...
Show 5 quoted lines
> 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).
...
> So, to shape it in form of a question: What is the optimal git-svn bridge
> setup?
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

Previous: Thomas Ferris Nicolaisen
Message 3 of 3 in “Git-Svn-Bridge”
  1. Christoph BartoschekNov 17, 2010
  2. Thomas Ferris NicolaisenNov 19, 2010
  3. Christoph BartoschekNov 21, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.