Git – Migrating From Subversion

Citing their website, Git is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do. Git is used for version control of files, much like tools such as Mercurial, Bazaar, Subversion, CVS, Perforce, and Visual SourceSafe.

What’s in it for ME?

Exact same reasons as I mentioned in Subversion With Apache post.

A month or so ago, you were big on Subversion. What changed?

Even as I was setting up Subversion, dear friend Jon DeVree (@nuxi) was after me to migrate to Git. At that time, having little or no prior experience with version control, I decided to stick with Subversion. A better excuse would be that I couldn’t get Git to compile on my linux box and setting up Subversion turned out to be relatively easier. And as time passed by, I happened read more about Git from their website [and elsewhere], the excerpts of which are given below for the sake of completeness:

1. Distributed development. Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh for authentication and security) or simply using HTTP – you can publish your repository anywhere without any special webserver configuration required.
2. Strong support for non-linear development. Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.
3. Efficient handling of large projects. Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other version control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.
4. Cryptographic authentication of history. The Git history is stored in such a way that the name of a particular revision (a “commit” in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.
5. Toolkit design. Following the Unix tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. Git provides tools for both easy human usage and easy scripting to perform new clever operations.
6. Besides providing a version control system, the Git project provides a generic low-level toolkit for tree history storage and directory content management. Traditionally, the toolkit is called the plumbing. Aside the user interface coming with Git itself, several other projects (so-called porcelains) offer compatible version control interfaces.

For any sane person who understood what (s)he was reading, this should have been more than sufficient to start the migration process. Having a lead block for head didn’t really help my cause and I needed one more nail to be hammered. Fortunately, Linus Torvalds himself did the honors, in his talk about Git at Google. Even if you aren’t like me, it’s worth watching:

Getting Started

It’s my practice to do a full/maximum installation of the OS and as such, that will ensure that most packages – though not everything needed – will be present, whether I use them or not. As such, I had Apache & Subversion [and other required modules] up and running but was missing Git. As is usual with me, I resorted to Dag Wieers repository – first to set up some yum things and then to install git.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# To be run as root - to configure RPM Forge
# Refer to http://dag.wieers.com/rpm/FAQ.php#B for specifics
rpm -Uhv http://apt.sw.be/redhat/el4/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el4.rf.i386.rpm
 
# Once this is successfully completed, add the following line to 
#/etc/sysconfig/rhn/sources and save the file.
#
# yum rpmforge http://apt.sw.be/redhat/el4/en/i386/dag
 
# To be run as root - to install git
yum -y install git
 
# Once the installation is complete, check the version (mine is 1.5.2.1)
# This may be required while fixing bugs/troubleshooting later.
git --version

Now that the system has Git installed, first thing one needs to do is to create a flat text file which maps SVN users to Git users. Let us suppose that this file is called $HOME/svn_git_user_map.txt and it would generically look like:

1

svn-username = Git User <git-user@someplace.com>

More specific example would be:

1

jill = Jill Thomson <jill_thomson@mydomain.com>

Let us now suppose that the SVN project that needs to be migrated to Git is called my_svn_project. Once migrated, let us suppose that it will be called my_git_project. Now, following the following steps / commands will migrate the SVN project to Git:

1
2
3
4
5
6
7
8
9
10
11
12

# Create a directory for our work
mkdir -p $HOME/git_stuff/my_git_project.tmp
cd $HOME/git_stuff/my_git_project.tmp
 
# --no-metadata tells Git to ignore all SVN details, except the commit log stuff
git-svn init http://svn.mydomain.com/my_svn_project/ --no-metadata
 
# Remap all SVN users to Git users during migration
git config svn.authorsfile $HOME/svn_git_user_map.txt
 
# Initiate the migration
git-svn fetch

Depending on the size of my_svn_project, it can take several minutes to finish the fetching process.

Once fetching is complete, the temporary repository – my_git_project.tmp – needs to be cloned to a normal repository. Doing so will result in a clean Git repository, sans any SVN material(s).

1
2
3
4
5
6
7
8
9
10

# Use 'git log' command to check the mapping of users and other useful information 
 
cd $HOME/git_stuff/
git clone my_git_project.tmp my_git_project
 
# Once it is certain that everything that's needed is actually there in Git, 
# my_git_project.tmp can be deleted
 
chmod -R 777 my_git_project.tmp
\rm -r my_git_project.tmp

One may refer to the excellent Git Documentation for commands and other material.