That bad taste you felt? That’s what real freedom is.

You don’t necessarily need to abandon SVN altogether. Here’s how we’ve been working during our transition phase – where some of us are using Git, and others are using Subversion.

Setup:
1) Either git svn init, or git svn clone the SVN repo (as you instruct). This then becomes the “Git/SVN Bridge.”
2) Fix up any of the branches, tags, etc… here. The svn/* refs are considered remotes, so if you want tracking branches, check these remotes out and create appropriate local branches. Also, check the tags out, and create actual tags. You MUST create local branches for any SVN branches that you wish to synchronize between Git and SVN.
3) Now, create a new bare repository (git init) somewhere, and from the bridge, push all the branches to the bare repo (git push –tags ).
4) All Git users now clone this bare repository (including you). Don’t do actual work from the bridge. The bridge will only be maintained by one (or a few) people that understand how to synchronize Git and SVN.

Sync’ing:
1) To update SVN trunk with changes on master, and vice-versa:
From the bridge:
a) git svn fetch (get new SVN changes)
b) git checkout master
c) git pull master (get Git changes from bare repo)
d) git checkout svn/trunk (checkout detached head)
e) git merge –no-ff –log master (merge changes from master). –no-ff insures an actual commit, –log copies individual log messages from each commit on master (–log is optional). git commit –amend can then be run if you want to edit the commit message.
f) get svn dcommit (This pushes your merge commit to SVN. Note that the commit was on a detached head, and is no longer accessible). All of your work on master (since the merge-base of master and svn/trunk) gets committed as a single change, and is now available to SVN users.
g) git checkout master
h) git merge svn/trunk (Gets the new updates from SVN – with the altered commit message – and merges to master)
i) git push barerepo (makes the SVN changes available to Git users)

That’s a lot of work, but by committing on the detached head, you essentially make that commit object inaccessible. This is a good thing, because the final git merge svn/trunk to master brings in that same change set, but with the new commit message (with the git-svn-id line). By the end, all of your Git users have access to the SVN changes, and vice-versa, and you avoid the massive amounts of merge conflicts that would result from duplicate changesets if you did the merge from svn/trunk to master, and then dcommitted from master.

The important thing is that there’s only one “bridge,” probably maintained by only a small number of people (who understand the sync process). Multiple branches (maintenance branches, for example) can be kept in sync this way by making the appropriate substitutions. The Git users (aside from the one responsible for the synchronization) never worry about SVN, and the SVN users never worry about Git.

Unfortunately, I can’t take full credit for this. This workflow is presented in Jon Loeliger’s excellent book “Version Control with Git”. I’ve added a couple extra steps that have worked very well for us.