Migrate from Subversion to git

Before converting a svn repository to git there are some useful tasks to do.

If branches are located at conventional locations (trunk, branches, tags), then it is as easy as

But if branches or tags are located at different locations, then one can specify those with --branches and --tags

And if there are multiple locations where branches and tags are located, it can still be done

unless there are multiple branches and/or tags with the same name.

In that case, it is still possible to use git-svn, but one has to adapt the config file manually.

git svn init does not accept --authors-file as a parameter, so you need to add it manually in the .git/config file.

After editing it, the .git/config file should look similar to

Note that there are multiple branches and tags values, but the "output" can be set at different locations. This way, there will be no collisions, just like there were none in Subversion.

First of all, in case of an error, even something like a network hiccup, you will need to clone the whole repository from the beginning. Also, even if the transition to git is flawless, it might still be useful to search for something in the old repository. With --no-metadata, any reference to the Subversion repository is lost. If you do not set that flag, all commit messages will have as additional comment a reference to the svn commit. Even if it might look ugly, the simple information that a specific commit has been made in svn and not git might be relevant, as changing repository technology is a big step.

Las, but not least, you could remove all those comments from the commit messages afterward with rebases, after the conversion is finished.

As mentioned before, cloning the repository can take a lot of time. Time increases exponentially if there are a lot of branches and tags. You might want therefore to skip some dead and experimental tags and branches if those are not important.

The downside is that adding those branches afterward is more complicated…​ so I would prefer to take over as much data as possible.

From time to time, the fetch will fail. The main causes I experienced were that either there was not enough memory (and the OS killed the process), or there was a temporary connection issue.

In those cases, just running git svn fetch will resume the fetching.

To automate it, just run it in a loop

Another source of error is if an author is missing from the authors.txt file. In that case, git will refuse to continue. Simply add the missing mapping name, and then continue with git svn fetch.

First, stop cloning as soon as possible to avoid duplicated work. Adding those missing branches and/or tags to .git/config is correct, but not sufficient.

AFAIK currently the only possibility is removing .git/svn/.metadata. In this file, git tracks how many svn revisions it has already checked. As branches might start at an older revision, we need to tell git to check them all another time.

After removing .git/svn/.metadata, do git svn fetch.

Finally git svn fetch finished to download all changes, it’s time to create "real" git branches and tags.

git already created the master branch (which is mapped to the trunk in SVN) and checked it out, but we need to take care of all the others.

Contrary to the example given in the git book I preferred not deleting the content of 'refs/remotes/svn', at least immediately, in case I need to update my copy another time (for example because people might still be working with the current SVN repository).

All branches except those created by git-svn can be pushed to a normal git repository:

In case the SVN repository got updated in the meantime, it’s sufficient to download the latest changes (git svn fetch) and use --force for updating all branches and tags (and remember to update the master branch too). As long as those branches have not been changed, it won’t be an issue, otherwise, it might be better to create a new branch with the changes.

Note: At this point, one could use git checkout master && git svn rebase, which is a git svn fetch, and it updates the master branch too. All other branches need to be updated as shown above.

Once the transition is over, it is possible to delete the SVN branches:

At this point, you have a mirror of the Subversion repository that can be pushed to a git remote. It’s time to see if everything looks as expected, like branches and tags.

As, at least in my experience, git and Subversion workflows are quite different when handling feature branches and merges, the history will look linear with merge commits that have a lot of changes at once. Unfortunately, AFAIK, there is no way to have merge commits like those I’m accustomed to when working with feature branches, where the merge commit has two parents.

In git, the history looks like

Here M has two parents, and ideally, it is an "empty" commit that just establishes the relation and brings the changes between A and B in M.

In Subversion the history looks more like

And M is a single gigantic commit (squash in git) with all changes between A and B put together. The information where the changes came from is stored in svn:mergeinfo, and while git-svn also takes advantage of it, the way it is implemented and used in practice (no central location, not always used, and last but not least different workflows), makes it hard to create the desired relation between branches.