So one of my more recent projects at work is/was moving our entire Subversion repository (for Sakai) to Git (using GitLab) & also moving our existing Subversion repo to our new repository/build server. This was done for a number of reasons.
- Git is better.
There were a few different parts to this process, some of which were fun and some of which made me realize that Solaris was made by Satan.
Here's a quick list of all of the different tech I'll be talking about
- Subversion - It also has a HUGE amount of client side programs too.
- Git/GitLab - This open-source repository is going to our main repo for developement projects.
- CentOS - This is what our virutal machines (servers) use as their operating system.
- Redmine - We use Redmine as our issue tracking software.
Step 1 - Freeze Current Subversion Repository
We don't want people committing to a repository after we move it since the older version would not be in use anymore.
This step ensures that people are not committing code to a stale repo. Once all of the conversion is done, people who commit code will be using the new repo and not the legacy one.
This would entail making sure that people have all of their local changes committed to the server.
Step 2 - Move Subversion Data To New Server
We have our Subversion repository on an NFS server so all we have to do is to add a mount to the data on the new host.
Step 3 - Upgrade Subversion To Newest Stable Version & Upgrade Current Repositories
For this step, I would just create a test directory for the current subversion code and run this script to update all of the repos in it.
for d in */ ; do svnadmin upgrade "$d"; done
What this little script does is iterates through each directory (repo) and then runs the svnadmin upgrade command to upgrade it.
Once I know this script works fine, I'd run it on the actual repo.
Step 4 - Transition Everyone To Newest Subversion Repo
This step ensures that everyone is working on the same repository and that no one is left behind in code. This step is essentially Step 1 & 2 and then having run the
svn relocate **NEW URL** command. This will switch the repository's external URL to the new one.
If you really wanted to make sure the new workspace was completely clean, you could just delete your old copy and then checkout the new one.
Step 5 - Install Git/GitLab
This step is pretty straightforward. We have a virtual machine that our git/svn/GitLab installations will run off of. I just updated it and ran the installer for GitLab and we're good!
This part will take some time since I’ll be configuring all of the projects and details within GitLab itself.
Step 6 - Convert Subversion Repo To Git
I'm going to hate this step since it takes a looooooooong time. I've ran through a few test conversions and it'll take hours even if I'm JUST converting trunk, not even counting the extra hour or so if I include the entire history.
What this step essentially does is re-create the entire history of the repository from Subversion into git.
This step will take hours.
Step 7 - Drink
Step 6 takes a LONG FUCKING TIME. Also, you might wanna work on that other little project you've been tinkering with.
Step 8 - Setup Syncing Hooks Between Subversion & Git
This one is going to be an on-going process. I am going to have to create a web-hook for the project so that it syncs it up with the repo over @ our Redmine server for issue tracking.
I'm also looking into somehow syncing up the issue tracking with Redmine since Redmine is our main issue tracker.
Steps 1-5 are going to be done shortly and once those are finished I can continue on with the other steps. Steps 6 & 8 will definitely take the longest time to configure.
The conversion over to GitLab will definitely help our developer team become more efficient and facilitate better teamwork.
Subscribe to Wills Thoughts
Get the latest posts delivered right to your inbox