Dev Blog

Exit SVN, Enter Git

by Jason Diller on May 16, 2011

In a move that was a long time in coming, we recently transitioned our version control system from Subversion to Git.

Impetus

Our development team has been growing rapidly, and we’re not finished growing yet. As a result, we often have several projects and features in development at one time. For maximum flexibility, we’d ideally manage those small projects by developing them on feature branches then merge them into the mainline trunk when they’re ready. That way, any kind of delay in one feature won’t affect any other projects that we have on the go.

We’re also flexible about letting people work from home some of the time, and using a centralized repository like SVN limits developers to working connected when they want to commit code. SVN can also be slow and unreliable over our sometimes crowded office upstream connection. All-in-all, Git is a much faster version control system.

Merge Pain

It’s hardly a secret, but merging branches with Subversion is difficult, has a high potential for error, and often causes enough grief that it’s not worth branching in the first place. As a result, people are a lot more likely to commit directly to trunk rather than make a branch where they can commit more often without disturbing others.

Enter Git

Again, this probably isn’t exactly breaking news at this point, but besides the distributed nature of Git, one of its most often cited features is its cheap and easy branches and pain-free merges. We chose Git over Mercurial other offerings which solve the same problems simply because it is the DVCS that the most of us had other experience with from our work on open-source software and other hobby projects. We have been using it for a while for some of our supporting applications, but hadn’t taken the plunge for our three largest repositories.

Preparing the Team

Some of our team members had never used Git (or indeed, any DVCS) at all, while some of us had been using Git-SVN for some time. In order to make the transition as smooth as possible, we gave everyone a lot of advance notice that it was happening, and held a “Git for Noobs” session to go over some of the basics.

Some good resources we shared with the team:

  • Git Ready – A free website with loads of articles subdevided into beginner, intermediate, advanced categories.
  • Pro Git – Scott Chacon’s book, available free online. We also have the dead-tree version in the office.

Implementation Details

Central Canonical Respository

Despite the distributed nature of Git, to maintain sanity, you really need one central repository designated as the canonical one for your team. This should be the repository your continuous integration server uses to create builds/run tests, and it should be the repository you release code from.

We host our central repositories with Girocco which provides a nice browser-based UI for creating repositories, viewing logs, etc.

Branching Strategy

Git supports a variety of branching strategies, and some successful ones have been documented in great detail on the web. We reviewed a bunch of them, and really liked a few, especially the one I linked to above.

Ultimately, we decided to take a page from the product development strategy known as Minimum Viable Product and minimize the amount of change we would impose on the team all at once. We fully expect to make some refinements to our process over time, but doing a big-bang change that included massive process changes as well as the tools change increased the chances we’d make mistakes, and make the transition more difficult.

Under SVN, ongoing day-to-day development committed to “Trunk”, in preparation for a release, we’d make a new branch for that release (“RC”) and our QA team would go to town making sure everything on the “RC” branch was production ready. Any fixes for bugs found during testing are committed to “Trunk” then merged on to “RC” On release day, our Ops team would take that branch and put it into production.

For Git, we’ve kept the same overall approach for now, but renamed “Trunk” to “Develop.” One drawback to this approach is that bug fixes have to be cherry-picked from the main development branch since we don’t want to merge in any other work. We could avoid cherry-picks by committing bug fixes to the “RC” branch then doing a merge of the release branch back onto “Develop” instead, a change we’ll likely make in the near future.

Master == Production

We decided to make the “Master” branch equivalent to the code that’s currently in production. That way if a developer wants to investigate some behavior currently happening in production, they can simply check out that branch and run it to see what’s going on.

Importing History

Everyone agreed (it seems like a no-brainer) that we wanted to import the subversion history so that features like ‘git blame’ would provide useful information and we wouldn’t have to keep a Subversion copy of everything around just to look through history. Thankfully, tools exist that import everything, and do it well.

Indeed, the git-svn tool that is part of current versions of Git can import SVN history, and even rewrite SVN author names into the more verbose “FirstName LastName <email@company.com>” format that Git typically uses, all you have to do is pass it an “Authors” file with the mappings.

We used svn2git by nirvdrum (Kevin Menard), which wraps git-svn and provides some extra cleanup after the import is complete. Specifically, it converts the SVN branches from remote branches to local branches in the resulting respository, which is something you definintely want.

Make the Switch

We opted for a big-bang switch rather than a phased-in approach so that we wouldn’t have to maintain two respositories and import changes on an ongoing basis. We chose our “code freeze” day as the date for the switchover, as that is the day our developers should have the least amount of work-in-progress (ideally, none) that they’d have to sort out as part of the switch.

Lessons Learned

A couple of us stayed late to babysit the migration and make sure everything was imported correctly so that it would be ready when everyone showed up for work the next morning. We learned a couple of things we can share that’ll make your transition easier if you’re doing the same.

  • Run the import on the same phyiscal box as the SVN server

    Our first attempt used SVN over HTTPS to read the data, but it was slow (despite gigabit ethernet), and eventually timed out, leaving the importation in a half-finished state. We moved over to the actual physical computer that served SVN and used the SVN:// protocol instead. It was much faster, and perfectly reliable.

  • Get your Authors file right

    We had to restart the importation a couple of times because of typos and omissions in the authors file. Git-Svn will bail out if you give it an authors file but finds a committer that isn’t in the file. If you have a lot of history like we do, it’ll probably take a while run through, and an error in the Authors file won’t show up until it tries to import a changeset from the affected author. Not a big deal if it’s the first revision, but a pain if if happens 80% of the way through the process.

Onward

We’ve completed an entire iteration on Git, including one release, so it’s probably safe to call the transition a success. We’ve already seen an uptick in the number of feature branches in use, and the dreaded “#&$*^@! TREE CONFLICTS” hasn’t been heard shouted from the developer pods since, and never will be again.

12 Comments (add comment)

May 18/11 7:52 am

Thanks for the article! A project I’m involved with is getting ready to make the switch to Git as well, and my own subversion repository is significantly less complicated. This article has given me a prod in the side to maybe transition my personal subversion server over to Git. Thanks again!

May 19/11 8:21 am

Great post – thanks for sharing. I’ve been using Git-SVN for a client who’s still using SVN, but I’d love to get them to switch over to Git. I hope articles like this one will slowly convince them to make the change, but what can I tell them to encourage them to switch?

Charles Simon says:
May 19/11 8:44 am

I agree that moving off SVN/CVS/… is the way to go , but what about Mercurial. I have heard that it is better than Git in many cases.

May 19/11 9:21 am

@Josh

It really depends on what their stated reasons for sticking with SVN are. A DVCS isn’t necessarily the right solution for everyone, but there are some really compelling arguments to switch in a lot of situations. I’d suggest not being belligerent and trying to find opportunities to clearly demonstrate how Git saved you some time or headache (thereby saving your client some money). If there are other developers on your team, try to get them using Git-SVN as well. Eventually it’ll be a no-brainer.

May 19/11 9:31 am

@charles

Mercurial is a fine choice as well. I don’t really think you can go wrong with either. Ignoring any technical constraints and outside influences, which one you choose is largely a matter of personal preference. Each have certain advantages over the other, so which one you choose is largely a result of figuring out what’s important to you. Either one will be a vast improvement over SVN though (in my opinion, of course).

ddbug says:
May 19/11 2:20 pm

@Jason The main problem of Mercurial is IMHO that it is too close to git by features. So users may think, why not to make some more effort and jump to git.

ddbug says:
May 19/11 2:23 pm

Stumbled upon another interesting DVCS, Fossil. Looks like a toy, but probably is not. Very convenient for quick ad-hoc sync or set up a small team server in 30 seconds.

Aug 20/14 3:43 pm

whoah this blog is wonderful i like reading your posts.
Keep up the good work! You understand, a lot of people are hunting round for this information, you
could aid them greatly.

Oct 1/14 8:29 pm

Touche. Great arguments. Keep up the amazing work.

Nov 6/14 8:06 pm

This will give you access to the bottom of the autoclave.
It was going to be the biggest thing in life I have ever done, and the first time I had been away
from home for such a long time. Second just sit down and have a conversation with
your teenager. From any ones behavior you cannot be confirmed on the note that he or she is illegal recreational drug addicted or not.
The findings proved the agency used was not capable of executing events in a
safe manner. Though it is true that these days the
methods of conducting drug test is becoming more sophisticated day by day but the still with the passage of time the methods and means to
avoid testing positive for every type of drug tests are also developing.
Learn everything you ever wanted to know regarding growing medical marijuana its benefits and marijuana legalization.

Leave a Comment ( *required)

*
*

*

Search