SVN to Git write-up

The older folks among you know that working with SVN is a pain. Let me tell you how I led the migration of a hundred projects from SVN to Git.

The backstory

I left my previous job about two years ago. As a small team in a single room, we didn't have significant problems with communication. Surprisingly the choice of tooling and the way we were using it caused our biggest problems.

The process

As a product company, we were working on a single monolithic project. We also had multiple smaller applications divided into SVN repositories. There's nothing unusual for a dozen years old products. But here's how we were using SVN.

There was no branching, staging environment or automated deployment. If we wanted to deploy a piece of code, we had to commit it to master. Then thanks to some cron job magic, it was deployed to the staging server. When we wanted to ship a feature, we had to ask the CTO to run svn up on the single production server.

The problems

Let me give you an example of a situation we had almost every day.

If George wants to test something on integration, he must commit his code to the master branch. A few minutes later, Mary finishes with her feature t already in master. Peter logs in to the server and updates the master branch on the server. Guess what happens at that moment? Peter just deployed George's buggy and unpolished code.

What was our workaround? We had to ask out loud in the room:

Is there something in the repository that we should not deploy?

And if the answer was Yes, we had to upload the specific feature files, revert the changes or even wait for each other to finish our work.

The solution

We knew that we had one major problem with our workflow. The obvious solution was to fix our workflow and keep SVN. Surprisingly we did not do that. I proposed to migrate to Git.

I was a fan of GitHub for open source projects. I've also used BitBucket for a couple of closed source ones. These tools helped me collaborate better with my peers and automate my processes. Unfortunately, both platforms were incompatible with the requirements of my boss. He demanded a self-hosted solution because he was afraid that the service providers could steal our code 😀.

We installed GitLab on one of our servers shortly after I started complaining about the process. The process was manual and tedious, but the documentation was good, and we did it without any significant problems.

GitLab looked great for us, but we didn't start using it. There was always something more important at the moment. It took me literally two years of negotiations to begin working on the migration from SVN to Git.

One day I organized a Q&A session with the CTO and the CEO. We started with a short presentation of some Git features and how the migration would improve our process. There were a lot of questions from their side. The CEO was concerned about the time it would take us to migrate. The CTO, on the other hand, didn't know if we could preserve the history of SVN. In my opinion, the CTO was used to the process and tooling and was afraid of the change.

I showed git-svn to the management and gave them a rough estimation of 3 weeks for the migration. Shortly after that, we started working on the migration.

The migration

Our first step was to set up a new GitLab instance. GitLab was shipping an Omnibus package. It made the installation and setup much easier. We created a new virtual machine and installed the package. The documentation was even better.

The migration of the test project went good, but I was frustrated when I started exploring all of our projects. As I already said, no one tried to learn how to work with SVN the right way. Only a few of the applications were using the standard SVN structure. Many of the projects were sharing a single repository and were separated only by their directories.

There were two directories in the repository of the main application. The one we checked out was the current version of the project (version here means rewrite). The other directory contained one of the previous versions. We also had a couple of other repositories for different old versions of the projects. I even found a project that was unknown to everyone. All these versions had their history representing different stages of the evolution of the same project.

The automation

Of course, we didn't migrate about a hundred repositories by hand. I described the structures of repositories and branches I wanted to achieve. Every project and branch had multiple fields like repository/branch name, SVN path, GitLab visibility and so on.

The rest was pretty easy. The main script executed a couple of shell commands and GitLab API calls. We cloned every SVN repository and converted them to a Git repository with all the history (commits, messages, and authors), ignored files and directories branches and everything we needed. Then we pushed the repository to a project created using the API.

The new workflow

As expected, learning the new tool was not easy. It took us about a month to get used to it and the workflow, but it was worth it. The process itself was nothing special. We were using GitLab for tracking issues and milestones progress, discussing issues and features, and everything else. Besides the better visibility, we got two huge benefits:

• Code reviews. They helped us improve our hard and soft skills so much.

• Feature branches. We were able to test every feature without the risk of deploying it to production.

The lessons

Know your tooling

It may be your editor, your version control system or your hammer. No matter your tool of choice, learn how to use it beyond the basics. If people responsible for our SVN repositories read just a bit about SVN functionalities we could have branches and code reviews for years, and the migration could be even easier if ever happened. After all, tooling is what makes us productive.

Do not be afraid of change

Change might be scary sometimes. It's natural for people to be afraid of the unknown, but it shouldn't prevent progress. We should look into our problems objectively, write them down, search for solutions and estimate the effort. Humans are supposed to be intelligent spices, after all.

What's your opinion?