Associating an existing Git repository to an existing SVN remote, with no common history

Question

I've recently inherited a project and would like to clean up the 'code delivery' workflow, by associating our internal Git repository with the client's SVN repository.

Repository Overview

My company has developed a software package for a client. We track our changes using a Git repository. Completely separately, we provide occasional code-drops and released binaries to the client's SVN repository. The file structure of the client's SVN repository is sort of a subset of our own file structure - it contains some files and folders, but not all.

Desired Workflow

Ultimately, I think I'd like to create a branch in our git repository called "ClientSVNDelivery". This branch should reflect the state of the client's SVN repo. Whenever we want to deliver updates to the client, I would like to git merge our changes over to that branch (from 'master'), and then git-svn dcommit those changes up to their remote site.

Problem

The problem I'm having, logistically-speaking, is the starting point. Since both repositories have a long, completely unassociated history and the folder structure is not identical (again, the SVN project is a subset of the folders in our internal git repo), I'm not sure how to create the associations needed to set up my 'ClientSVNDelivery' staging branch (namely, how to form a common ancestor that would allow a merge to actually work). To be honest, I'm even having trouble describing what I want to do!

Would I create the branch off of our most recent internal revision? Some arbitrary earlier revision? Or would I branch off of the remove-svn history instead?

Question

Has anyone dealt with this kind of scenario before? Were you able to streamline the process, and what steps did you take to set up your intermediate branch? How did you create the history associations?

Answer 1

Don't know the fast and nice solution for what you described, but, one of possible ways, I think, is to create a Git branch from latest SVN branch - this will give you an ability to deliver code to client using Git. Than you can continue work with your branches in Git and cherry-pick changes only in specified paths to that "ClientSVNDelivery" branch as described here (you can write pre-commit hook to discard changes in paths you don't need in "ClientSVNDelivery" branch)

Answer 2

You can interact via git with a remote SVN repository by using the git svn subcommand. Read it's manual page (there are several caveats due to SVN limitations and impedance mismatches). I haven't tried to use git svn to suck down a SVN repository and then cut loose, but I don't see any reason why it shouldn't work.

If you go the git svn route, be advised that SVN isn't really set up to suck out the whole history of the project, this process can take a very long time. If it crashes or otherwise stops without getting all, you can restart it (at least most of the time) and it continues its task.