Torben Hansing Torben Hansing - 3 months ago 12
Git Question

Convert SVN Repository with multiple active branches to GIT

I'm trying to convert my SVN Repository into a GIT repository.
The problem with this is, that in the SVN there are several active branches for
different software versions maintained in parallel.
So the SVN setup looks somthing like this:

SVN ROOT
|- trunk
|- branches
| |- v1
| |- v2
| |- v3
|- tags
| |- v1
| | |- 0
| | |- 1
| |- v2
...


Now I want to create a GIT repository with a branch for each of the branches of
the SVN. Creating the repository and porting the tags is not a problem at all.
I'm doing a

git svn init -s --tags=tags/v1 --tags=tags/v2 <REPO_URL>
# modified .git/config to use tags/v1/* for the tags of the different versions
git svn fetch


and after this I get the branches as desired and I'm able to check out the different software versions by using

git checkout -b v1 origin/v1


The Problem is that the SVN Repository is verry old and the different branches all branch from the trunk. But my development requires me to fix a bug in
v1, merge it to v2 as well and dcommit everything back to SVN.

So my question is what's the best way to get clean (mergable / rebaseable) GIT branches? And how should the workflow with this be?
Should I add a new branch for each version in GIT, let's say svn_v1, rebase the v1 into this and then dcommit from there? Or what's the best way to get the commit back to SVN?

EDIT:

I've already tried to rebase the different branches according to the merge upstream (e.g. rebased v2 onto v1 and trunk onto v2) but this messed up
my histroy and when trying to dcommit it wanted to commit all the commits that I've rebased on top of the current history. This would make the SVN history messy as these commits already are in the Repo.

EDIT2:

To make the problem more clear. Imageine the following history:

D--E--F v1 K--L--M v2
/ /
A--B--C--G--H--I--J--N trunk
^
|
introduced a bug


As commit
B
introduced a bug, all branches
v1
,
v2
, and
trunk
are affected. The policy of my company is now (in SVN) to fix this issue in the lowest affected branch (
v1
in this case) and then merge the commit through the
branches up to
trunk
.
How does the workflow look like to do the same thing in GIT, such that in SVN the commit in
v1
is marked as being merged into
v2
?

Answer

Ok, I've finally managed to solve this issue myself. I've solved this in two steps: First of all, as our code bases for v1 and v2 are good (building and working, both with the known bugs fixed), I've recorded a merge of the v1 branch into the v2 branch and v2 into trunk in svn. Now I am able to merge the branches in git. Then I've found this passage in the git-svn docs:

config key: svn.pushmergeinfo

This option will cause git-svn to attempt to automatically populate the svn:mergeinfo property in the SVN repository when possible. Currently, this can only be done when dcommitting non-fast-forward merges where all parents but the first have already been pushed into SVN.

So I've enabled this config value

git config svn.pushmergeinfo true

and now, if a new bug is found, I'm fixing it in the lowest version that has this bug, dcommit it to svn, and afterwards merge it into the next version using the --no-ff option. If I dcommit now from there, the mergeinfos in svn get updated and everything is ok.