Combining SVN and Git

Question

I just got this wacky (stupid?) idea in my head, where I thought of tracking the same folder (project) with both Git and Subversion at the same time; that is the folder/project will have both .svn and .git directories.

I didn't find anything relevant in my searches, so that's why I am throwing the idea here to assess its pros and cons (if any). What I am probably looking for is: Why this strategy can't or shouldn't be used?

Q: Why would I want to do this?

We already have a Subversion repo on the network, with over 1 year of history + svn:externals + linked to bug tracking + hooks. But I want to have the flexibility of a DVCS, such as Git, so that we don't have to be connected to the network to commit our work; so that we can work remotely as well.

Q: But I can use git svn!

Unfortunately, Git svn doesn't support svn:externals. And git submodules are not the same as svn:externals.

Q: What could be achieved with this combination?

Flexibility of Git: code can be edited and committed locally without being connected to the network; also, pushing the repo to production or staging server or to a colleague would be a piece of cake.

Centralization and external repo utilization of SVN: with effective utilization of SVN:externals, we will be saving ourselves a lot of work, and then the developers are already familiar with SVN.

Ideally, I would like to make a complete switch to Git eventually, but for now, because svn:externals makes it super-easy to integrate external repos, keeping subversion intact makes sense.

Answer 1

This strategy will absolutely work; I've used it, albeit fairly briefly, and I know other developers in my company have used it for longer periods. That doesn't mean it's easy, however.

You'll find you need to do a lot of work to keep Subversion and Git in sync. As a simple example: when you do an svn update, you'll also need to do a git commit -a or similar, else Git will think your working copy has a load of changes that Subversion knows are up-to-date with the remote repository.

This gets much more complicated if you need to svn update -r to see an old revision for some reason, or try an svn switch, etc.

Depending on whether you have Git track your .svn directory, you'll hit other problems. If you don't (ie, you put .svn in your .gitignore file or similar), you'll find it much harder to use Git's branching features. Consider the following workflow:

1. Create a Git branch to work on a feature.
2. There's a recently checked in bug in the Subversion repository you need to fix! Switch back to your main Git branch, svn up and git commit, so you have the latest code, fix the bug, git commit and svn commit it.
3. Checkout your Git feature branch again. Since this is based off a different Subversion revision, Subversion now thinks there's a load of changes in the working copy.

Alternatively, you can have Git track the .svn directory. This avoids the above problem – when you checked out the feature branch again at step 3, you'd also checkout the Subversion metadata from that time, so Subversion knows the correct revisions that everything's based off.

Sadly, Subversion was never designed to be used this way. In Subversion 1.6 (I don't know about 1.7), the .svn directories may contain significant empty folders. Git doesn't track empty folders, so these can be lost between Git operations, breaking the Subversion working copy. I know one developer who wrote a bunch of scripts to fix up such mangled .svn directories, but that's not trivial, and very fragile.