About Samuel Santos

Java and Open Source evangelist, JUG leader and Web advocate for web standards and semantic technologies.

Migrating from a Subversion repository to GitHub

One of greatest attractions of GitHub is the community and the tooling that allows this community to share code. Each contributor can clone the repository, make their changes and then send you a pull request. As the project maintainer your job is now a whole lot easier and more manageable. No more patch files to worry about.

Follow the recipe bellow to move your SVN repo to Git.
Best of all, you get to keep the entire commit history of your project.

Git author data

The first step is to create a text file mapping the SVN users into Git authors. The format is:

samaxes = Samuel Santos <samaxes@example.com>

To get a list of the author names that SVN uses, you can run this (on OSX the grep parameter is -e for a regular expression instead of the -P):

$ svn log --xml | grep -P "^<author" | sort -u | perl -pe 's/<author>(.*?)<\/author>/$1 = /' > authors.txt

Note:

If the command-line is not your thing and you are migrating from a SourceForge Subversion repository, use the code in FindSVNCommitters.java together with SourceForge backup tool: rsync to get the complete list of author names.

Create the Git repository

Next, create a new Git repository for your project. This will be a local repository for now so there’s no need to worry about GitHub just yet:

$ git svn clone http://my-project.googlecode.com/svn/ --no-metadata --stdlayout --authors-file=../authors.txt my_project

Notes:

Without the --no-metadata option, git svn adds a reference to the SVN revision number in every log message.
If git svn encounters an SVN committer name that does not exist in the authors-file, git svn will abort operation.

Clean up SVN references

The initial clone imports everything including SVN branches and tags, however only a master branch is available locally:

$ git branch
* master

The svn-related branches and tags are actually remote branches in Git:

$ git branch -r
  tags/v1.0
  trunk

So, to move the tags to be proper Git tags, run:

$ git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done
Deleted remote branch tags/v1.0 (was 539f804).

And move the rest of the references under refs/remotes to be local branches:

$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done
Deleted remote branch trunk (was e4b45d8).

Now we have all the tags and branches locally:

$ git tag
v1.0

$ git branch
* master
  trunk

However, the local trunk branch is redundant with our Git master branch and should be removed:

$ git branch -d trunk
Deleted branch trunk (was e4b45d8).

Push the code to GitHub

Now all the old branches are real Git branches and all the old tags are real Git tags, it’s finally time to push the code to GitHub. For that, create your new repository on GitHub, and:

  1. Add your new GitHub repository as a remote:
    $ git remote add origin git@my-git-server:myrepository.git

    If you get the error “fatal: remote origin already exists“, do the following instead:

    $ git remote set-url origin git@my-git-server:myrepository.git
  2. Push the code to it:
    $ git push origin --all
    Counting objects: 32, done.
    Delta compression using up to 2 threads.
    Compressing objects: 100% (24/24), done.
    Writing objects: 100% (31/31), 10.85 KiB | 0 bytes/s, done.
    Total 31 (delta 6), reused 0 (delta 0)
    To git@my-git-server:myrepository.git
       78ffd8f..f50e329  master -> master
    
    $ git push origin --tags
    Counting objects: 1, done.
    Writing objects: 100% (1/1), 219 bytes | 0 bytes/s, done.
    Total 1 (delta 0), reused 0 (delta 0)
    To git@my-git-server:myrepository.git
     * [new tag]         v1.0 -> v1.0

All your branches and tags should be on your new GitHub repository in a nice, clean import.

Happy pushing!
 

Reference: Migrating from a Subversion repository to GitHub from our JCG partner Samuel Santos at the Samaxes blog.
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

One Response to "Migrating from a Subversion repository to GitHub"

  1. Bart says:

    This is a good reminder for people to migrate to Git.

    The instructions in your post however are basically translated from the free Pro-Git book [http://git-scm.com/book]; maybe you should reference it in the article.

    While the basic instructions work well for regular Subversion repositories, I’ve come across a few that were quite messed-up. The basic migration couldn’t migrate most of the tags in these repositories. I shared a trick to fix this (and get the tags with their history in the Git repo) on Coderwall: https://coderwall.com/p/dj4jda

    Thanks for sharing.

Leave a Reply


+ one = 3



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books