General workflow for git-svn bridge for 2 teams

Question

Lately I read many things about GIT-SVN bridge, tried it myself but somehow I fail when things get rough.

The environment We are 2 teams: once uses SVN, the other is rebel and uses GIT. In order to sync, I created a bridge between the 2 repos. The SVN team has x developers pushing 10 times a day and having mostly a red build, GIT team has 6 developers and they want to fetch only once a week or when they have something to commit so they keep the build mostly green.

Use case: The "bridge" is not automated (yet), therefore it is on my computer so I am responsible to merge branches and dcommit them correctly. So, the GIT team is splitted in 2: some of them working on branch "branch1" and the rest working on "branch2". They always work in pairs so when "branch1" is done, we create another branch for next task.

What I tried to do: In order to keep it clear, I created a branch from master called "masterSpace". I do git-svn rebase on master every morning, then I merge the changes into masterSpace. A developer creates from masterSpace "branch1" when needed where devs commit stuff. When they are done, I have to commit everything on SVN. I tried like this

merge "branch1" into "masterSpace".
checkout master
git svn rebase
git rebase masterSpace
git dcommit
git checkout masterSpace
merge "master" into "masterSpace". 

Then a developer would create a new branch from this masterSpace having everything up-ti-date and the process repeats itself

Problem: I tried this with branches that had a single commit and worked great, but things got rough after like 2 weeks of work ... then my workflow failed. After I decommited , the same commits had different IDs on master and on "masterSpace" so next time I was trying to dcommit I got hell of a lot of conflicts. Even after I merged master into masterSpace. I even tried a simple scenario where:

 I have a "branchX" with changes
 I merge them on "masterSpace"
 rebase them on master and finally dcommit them.
 Then I made a single change on "masterSpace" 
 I rebased it into "master"

After this, I was like 10 commits ahead (because of the IDs of the previous commits I guess). So...dead end

Q1: Solution? What would be the correct workflow for our environment and usecases so that both GIT and SVN teams can sync and work peacefully ? I decided that the "masterSpace" is redundant and it will never work as I imagined. Still, I have to find a fast solution for the dcommits so my team won't lose time or code. Some helpful information: we change a branch every 2 weeks aprox. After we finish, we can throw away the used branch and create another one from the master

Q2: How to make everything automatically? In the near future I plan to move my "bridge" on Jenkins. Would it be possible to find a solution to make it work automatically? Something like merging a branch on "jenkinsbranch". Jenkins automatically builds this branch, if its green it dcommits it, if not, waits for another push that will fix the build

In my initial scenario, I planned to have the "masterSpace" as "master" on jenkins. A developer would merge his branch into "masterSpace", jenkins would make a svn-rebase and build it automatically, if it is green then dcommits all the changes. Else, it waits for a dev to fix the build. But... seems like I was wrong.

TL:DR What would the normal workflow be when a team works on 2 different branchs for a couple of weeks and wants to dcommit them in SVN (and be in sync with SVN) ?

Answer 1

I have worked in such environment with git-svn and can say that the sync is difficult to make smooth when the rate of changes/conflicts is high both sides. In your setup I would try to look whether SubGit is as good as they claim to be.

If you stick to git-svn, couple of techniques that might potentially make your life easier:

• Try to avoid merges and use rebases everywhere. Including working branches. Answering Q3 - do regular rebases of your working branches against your masterSpace or master .
• I would keep your masterSpace separate for convenience of syncing. In my case I called it master where the svn branches would use svn prefix, eg svn/trunk . Similarly for other mirrored svn branches. I will use my naming further.
• I wouldn't rebase master onto svn/trunk . Instead I would first rebase changes from svn/trunk onto master , if any. At this point I make a technical merge of the svn/trunk into master . The state of these revisions should be equal (you may check git diff svn/trunk master ) so in case you get merge conflicts - just do merge with -s ours , although I think the recent versions of git were smart enough in this case. Now that master is equal to svn/trunk and git knows about this via the technical merge, I would rebase the changes from the working branch being merged onto the top of master , carry the master to those changes ( git push . HEAD:master ), take a detached HEAD of the resulting master , and do a dcommit to svn/trunk . At this stage we will get svn/trunk and master again having same contents but different revisions due to svn dcommit. Again, I would do a technical merge of svn/trunk to master to mark a point of equality.