Git users in an SVN shop, organising our repos

Question

I work in an SVN shop, but to inject a bit of sanity in my work I use git-svn. A growing number of my colleagues are seeing the light as well, and now we'd like to, in some cases completely side-step SVN. Currently we each have our own git-svn repo, but due to wildly differing hashes we can't really share anything except plain patches or via SVN. How should we organise our repos in order to allow direct sharing (via git-remote)?

The only way I can come up with is a single, shared git-svn repo, which we use as a gateway to SVN, but that'd probably be a bit cumbersome to work with--it'd be much better if we all could push to SVN directly from our own git-svn repos.

Edit: Unfortunately I don't have admin access to the SVN server, so solutions like subgit are of little use at the moment, even though they are of interest.

Answer 1

You may look at subgit:

SubGit is tool for a smooth, stress-free Svn to Git migration. Install it once on the server side and use both Subversion and Git as long as you like.

SubGit lets one to set up a bidirectional Subversion to Git replication (writable mirror).

And:

SubGit is a solution for a company-wide migration from Svn to Git that is:

Much better than git-svn (see comparison);
Requires no changes of the infrastructure that is already in place;
Allows one to use all Git and all Subversion features;
Provides genuine stress-free migration experience.

Answer 2

Bidirectional gatewaying between two different version control systems predates git by ages. I have already been doing it by hand between CVS and Arch some 10 years ago. If you don't want to buy subgit, you can maintain the gateway manually or even try to script it. The workflow is simple:

• Have two branches, trunk and master. trunk mirrors subversion, master is plus the changes developed in git
• Whenever there is new change in subversion:
  1. $ git svn fetch
  2. master$ git merge trunk
• Whenever trunk is pushed:
  1. trunk$ git merge master
  2. trunk$ git svn dcommit
  3. master$ git merge trunk
• You should do both sequences atomically, i.e. only one operation at a time.
• You may consider setting git-svn up so it does not rewrite the commits with the subversion revision info to reduce the number of merge commits in git.
• It can be done for multiple branches, but I don't think merging separate subversion branches in git could work.

Answer 3

We are in exactly the same situation. What we have is (warning, some pseudo-code!):

• remote git repo, scripted (using bash scripts), cannot be --bare

• a pre-receive hook that checks the username, then per each ref received and for all SVN-mapped branches: (git -> svn):

  • git checkout -f <branch>
  • git reset HEAD --hard
  • git clean -fdx
  • git merge -n $newrev
  • git svn dcommit

  • if failed, revert all,

  • then, after all loops - update all SVN branches (using the script, see below)

• a cronjob updating git-svn branches with latest svn changes (svn -> git):

  • git checkout --orphan svn-update <random-branch-name>
  • git svn fetch --all
  • for all git-svn branches: git branch -D <branch> && git branch --track <svn-branch> refs/remotes/<svn-branch>,

• ssh keys for git authentication

• users-managed SVN authentication (based on git usernames, this will depend on your setup)

This way no one uses SVN directly and the only difference vs pure git is you cannot change git-svn branches history (as SVN will not let you dcommit that).