transparent git-svn gateway

Question

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.

Answer 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.

Answer 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.

Answer 3

You basically have two options:

1. Allow git-svn on the client side to solve the problem. Your initial checkouts will take awhile, but it can give you the all the same features as a native svn checkout (including pushing and pulling through git svn dcommit and git svn [fetch|rebase]), and if you clone it with --stdlayout, you get full branching and tagging support. (I do this at my company--I'm one of two employees who uses git with the svn server, and I don't have any trouble.)

2. Clone the repository with git-svn onto another server (or even the same server), and then just start hosting git from that repository. Then you've got a native git repo, with all the svn data in it from before.

Answer 4

If you don't want to "git svn clone" on each computer, you can:

1. "git svn clone" once, then distribute the repository to each computer. [Simplest, but not exactly you require].
2. Do as Mickey say in point "2." ("Clone the repository with git-svn, and then just start hosting git from that repository") and run two hooks: one brings commits from git to svn (if there are no conflicts), the other brings commits from svn to git (if there are no conflicts). This can be complex (especially if consider branches/tags), and that two repositories will get diverged when both SVN and Git are written. This can work as transitional scheme (before going to point "3."), but bad for settling on it.
3. Do one-time "git svn clone", drop SVN repository, host only Git. [Simple, but not what you require].