2

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?

BTownTKD
  • 7,911
  • 2
  • 31
  • 47
  • 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](http://stackoverflow.com/questions/5717026/how-to-git-cherry-pick-only-changes-to-certain-files) (you can write pre-commit hook to discard changes in paths you don't need in "ClientSVNDelivery" branch) – tijs Feb 27 '14 at 18:47
  • That is an excellent option. If there's no way to jury-rig a common ancestor between the two branches, I think this is the option I may go with. (You should post an answer; even if there's a better option, it would sure get my upvote.) – BTownTKD Feb 27 '14 at 19:00

2 Answers2

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)

Community
  • 1
  • 1
tijs
  • 566
  • 4
  • 12
  • I've accepted this answer for now, with the grumbling caveat that it could be a real pain in the ass to cherry pick every single relevant commit that I want to push to my client's SVN server. – BTownTKD Mar 06 '14 at 02:38
-1

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.

vonbrand
  • 11,412
  • 8
  • 32
  • 52
  • Thank you for the input, however I already mentioned 'git svn' in my question; I intend to use it. The question is more about the strategy of creating associations and 'common ancestors' between two unrelated histories - one created by 'git svn' and the other being the primary, pre-existing git history. – BTownTKD Feb 28 '14 at 01:58
  • How will you want to stitch together two separate histories? As a first step you need to take both to the more flexible system (git) and then import one in the other. I merged two repositories by essentially pulling one and fixing up the merge, but I had made sure beforehand that only a few files were common to both. If this is really what you want, you will have to give a *lot* more detail. And I doubt anybody who can't take a closer, hands on look will be in a position to help. – vonbrand Feb 28 '14 at 16:13