Migrating a project from SVN to GIT

Prerequisites

I assume that you have read Chapter 1 - and worked out an example all by yourself

Initial SVN Setup

I assume that in the past you have the same setup as discussed in Chapter 1: a central repository on a shared server, say \\SERVER\SVN\SUPERSOMETHING

The big picture

Actually, this process involves several steps:

  1. Setup a proper SVN server. This is needed because SVN migration from files often fails.
  2. Clone the SVN repository into a regular (read: local) GIT repository. The GIT repository will have the complete history (like all local GIT repositories do), but other users won't be able to check out from THAT. Therefore:
  3. Create a bare GIT repository (the one that will be used to host the repository on the server), and push the local to the 'scheduled-to-be-remote' bare repository.

Setting up a proper SVN server

There are a couple of SVN-to-GIT migration tutorials out there, but when following most of them I ran into the same project: file-based repositories on Windows are considered semi-broken by Linux-Lovers and thus migrating them directly failed for me, each and every single time. Instead, I have come to the opinion that your best base is to first setup a proper SVN server, then migrate from there. A proper SVN server is a HTTP(S) based one, so we will do that first. In the following I will use the brilliant VisualSVN Server, which is free for non-commercial use. You can also setup a SVN server using XAMPP, though that might be slightly more involved. For now, we use the simple option.

Step 1: Download VisualSVN: go right ahead and install it. Default options should be fine. Once you start the server, you'll see something like the following:

Step 2: Create a VisualSVN user: right-click on the 'users' folder in the VisualSVN GUI and choose 'Create new user':

Step 3: Let VisualSVN serve your existing project: copy the complete existing archive (not a checkout, the \\SERVER\SVN\SUPERSOMETHING directory!) to the VisualSVN repository directory you choose during the installation. For my VisualSVN install, this is H:\Repositories, so I copied the complete folder.

Step 4: Refresh VisualSVN repositories using the F5 key (or right-click on Repositories and 'Refresh').

Your project should now show up in the list of available repositories. In this example, I copied the SVN repository that holds this website. If you select a project, you will see the repository URL, typically something of the form http://YOURMACHINE/svn/YOURPROJECT.

Here, it is https://GK2014/svn/website/.

Step 5: Grant your user access to the repository: right-click the repository and choose 'Properties'

Then click 'add' to add your user

That's it! Wasn't too bad so far, was it?

Cloning a SVN repository into a local GIT repository

Step 1: From now on we have to say 'good bye' to the TortoiseGIT GUI for a moment and stick with GUI bash. Create a working directory, then right click it and choose 'Git bash':

A GIT bash will popup:

Step 2: Now, create a local clone from SVN

From the GIT bash, run this command:

git svn clone https://YOURMACHINE/svn/YOURPROJECT/ --no-metadata --prefix=origin/

Note a couple of fine-points:

Note: this will take a long time. Even if your project is small, it takes noticeably longer than most other operations in GIT; if your project is large, then prepared to spend a couple of hours waiting for the process to finish. If I were you, I'd not touch the SVN repository while you do the import, either. Well, if you take a close look you'll see what it is that GIT actually does: it goes through the SVN log and checks out each and every revision individually, in order to reconstruct the history. No wonder this takes so long!

Pushing the local repository into a bare repository

As discussed in Chapter 1, 'bare repositories' are what you need if you intend to have one central repository that everybody uses to sync. So, now that we have a local repository, we need to push it to a bare one.

Note: In the following, I assume you are in a directory /T/TEST and have just checked out YOURPROJECT, so a subdirectory /T/TEST/YOURPROJECT exists.

Step 1: Create a new bare repository and initialize it. From GIT bash, run this:

git init --bare YOURPROJECT.git/

Remember that there is a naming convention that bare GIT repositories end with .git. This command will create a subdirectory YOURPROJECT.git in the local directory, initialize it and make it bare.

Step 2: Switch over to the local repository by running

cd YOURPROJECT

Step 3: Tell the local repository that its bare 'master' (terminology badly off here, bare with me for a moment) is the new 'bare' repository:

git remote add bare ../YOURPROJECT.git/

Step 4: Tell the local repository that its bare 'master' (terminology badly off here, bare with me for a moment) is the new 'bare' repository:

git remote add bare ../YOURPROJECT.git/

Step 5: Push the local repository to the remote one using this:

git push --set-upstream bare master

Done. Phew. Take a deep breath.

Switch to the correct working directory

At this point, you have

So logically, the next step is to check out a local copy of that, and start working from there. Try a few commits, do a push, just to verify things work as expected.

Using GIT from Visual Studio 2010

For Visual Studio 2010, there is the Git Source Control Provider, which allows you to control the most important aspects of GIT from within Visual Studio.

Step 1: download the Git Source Control Provider and double click it. It will install it.

Step 2: Restart Visual Studio 2010

Step 3: If you have an open solution that is currently managed by Subversion, you must close it first and then manually do the following:

Next

Unfortunately, I am still working on the next chapter, so you are finished ... for this time!

GK, Sept. 14, 2014