transparent git-svn gateway

Currently we have an subversion repository with the following layout:

• /trunc
  • /group1
    • /proj1
    • /proj2
  • group2
    • /proj3
    • /etc..
• /tags
  • /group1
    • /proj1
    • /proj2
  • group2
    • /proj3
    • /etc..
• /branch
  • /anything temporary

I believe this is an rather bad layout, but at the moment it's difficult to change it fully.

Personally I dislike subversion, due mostly the long time it takes to check history, and also that branching and merging are cumbersome etc. so I really want to use git instead.

Sadly we cant just switch to git as the mental capacity for some might be to overwhelming, so I was looking into git-svn to see if I could practically use that to solve the issue.

Sadly that directly ends up in a bad situation as I want to break down each project into one git repo, and I don't want to have to recreate the git-svn checkout on each computer I work on. so I though perhaps there is an possibility to create some sort of transparent git ←→ svn proxy/gateway, so that an push to that repo "commits" to the svn repo, and an commit to the svn repo updates the git repo.

Google hasn't been my friend, have only found generic usage help to use git-svn, so I ask you if you have some good ideas to accomplish this.

Solution 1:

For transparent Git/Svn gateway you may use SubGit, it matches your requirements very well, except that right now it only supports either simple single-project (/trunk, /branches, /tags) or multi-project (/project/trunk, ...) layouts.

Solution 2:

If you do not control or do not want to mess with the Subversion server then you cannot use SubGit. What you could do in this case is to have a automatically synchronized git repository for each trunk. Our team works this way - we have a git-Subversion bridge that synchronizes changes between our team git repository and the project's trunk in the corporate Subversion repository so that our git usage is transparent to other Subversion users.

The setup is described in more detail at https://github.com/mrts/git-svn-bridge.

We have used this setup in production for more than a year.

I guess the biggest caveat of the setup is that git branches will be squashed into one commit during merge to trunk. For us this is no problem - we use short-lived task branches and consider them to be lightweight, ephemeral "units of work" that can go to mainline in a single chunk - and the branch history is retained in git.