SVN to GIT migration - maintaining history when the SVN repo has had a lot of movement

Louis Burton

I have been following this guide to try and enable us to move to bitbucket:
https://www.atlassian.com/git/migration#!migration-convert<br< a="">>
I have managed to git svn clone our SVN repository that we want to host in bitbucket. I used a command like:

git svn clone --stdlayout --authors-file=authors.txt svn://svnrepo/a/b/project gitproject

Unfortunately though, upon inspection, I notice that the git log (with --follow) does not go further back then the latest SVN repository move for each file. Using an svn client to the SVN log for the same file will track back further.

The history is that the project has evolved and was mavenised, resulting in movement from different locations in the same repository, but outside of the project location we're trying to migrate to GIT. The project has a long history, and movement and restructuring of the repo is to be expected over this time period.

The issue seems very similar to this which I found:
https://github.com/githubtraining/feedback/issues/43<br< a="">>
However his workaround seems unachievable for us due to different parts of our project having moved from different locations at different times (and sometime multiple times), rather than one big bang move to deal with.

Any help with this would be greatly appreciated. I don't want to lose our history and I'd really like to get the clone done properly over the weekend. Thanks in advance.

Louis Burton

In the end, I tried git svn, subgit and reposurgeon. I found similar issues with git svn and subgit. reposurgeon did seem to do more, but it kept hanging for me when removing empty revisions, and the svncutter tool for debugging would also hang.

I managed to accomplish my goal via two different means.
1. Manually grafting together branches. I git svn cloned the main repo, and then I would clone the various locations needed. With each history location I'd potentially rewrite history with filter branch to get them to structure that would join the main clone history nicely. I'd then add them as a remote and fetch them. Then I'd graft all the pieces together and at the end rewrite the full history. This was very labour intensive for our repository as it needed over 40 grafts, picking out references of interest one by one. You could probably do something similar with git replace, but I used grafts.

2. I also managed to get it via a simple git svn clone, but this time cloning the whole root of my svn repo and using a complex regexp in ignore paths to make sure only the paths that history had existed on was included. This took an incredibly long amount of time (like a week), but in the end, it would stitch history together appropriately. I did not include branches or tags, as this seemed to confuse the history.