Confession: I don’t use Subversion.

The software developers at Princeton Satellite Systems use Subversion to manage revision control.  Usually, we don’t use branches.  We work locally and commit changes to the trunk when we feel that we’ve finished a chunk of code, and we haven’t broken anything.   I had no problem with this until …

About two years ago I ran into a merge conflict  / reversion problem while trying to use Subversion branches in the way that they are intended to be used. I don’t remember the details, but I do remember that the process of fixing things was painful and time consuming.  I never again tried to use an svn branch; I worked locally.   I also wondered if there were a better way.

Google advised me that lots of people had problems with merging and branching while using svn.  And reverting to earlier versions was non-intuitive.  In fact if I remember correctly (and I may not), you can’t really revert in svn.  Rather you merge in a previous version of your work.  So your history becomes <old working version> –> <new broken version> –> <old working version>.   I may be entirely wrong about all that; I really don’t remember very well.

Other people with the same complaints said that they switched to Git, or Mercurial, or Bazaar.   I took a look at all three, and decided to try Git.  The reasons:

1. Git can be used to manage a Subversion repository
2. Git can be used off-line for most tasks.
3. People report that merging goes smoothly
4. People report that reverting is trivial
5. People report that branching is trivial

After a period of learning, I learned that all of the above are accurate.  I now rarely do anything directly in svn.   And then later Apple integrated Git into Xcode (although I never use that integration feature) which made me feel a little better about choosing Git over Mercurial or Bazaar.   I now use branches liberally, every day, to try out ideas.  I create branches and destroy branches with abandon, and when I’m ready I merge my work into the “main branch”.  Git keeps all of the things I tried (until I’m ready to ditch them), and I can switch between them instantly and effortlessly.  If I want to see how the application behaved three revisions ago, that’s also effortless and instantaneous, as is returning to my current working state.

I chose not to tell my colleagues about this subterfuge.  The reasons:

1. Git is not so easy to learn if you are starting from a knowledge svn.  For some reason, the Git developers chose to use the same words (like “checkout”) to mean things that are entirely different from what they mean in svn.  (What’s up with that?)
2. There’s no reason that anyone has to change a workflow that works for them, especially if there’s a learning curve to endure.
3. Git is structured very differently than svn.  My brain revolted for a while.
4. It took me a while to get comfortable with Git, and even now I’m get a little nervous at times.  But then again, I’m nervous at times using Subversion.

I am now a gitophile.  The main advantages from my point of view are:

1. A copy of the entire repository is kept on your local machine.  (In fact, strictly speaking you don’t need a central repository.)  So you don’t have to be online to use Git (except to push your changes to a central repository if you have one).   
2. Creating and destroying branches is fast and easy.
3. Reverting to any previous rev is fast and easy
4. Revisions can be assigned names at any time, so I don’t need to hunt for revision numbers.
5. Merging branches seems to work quite smoothly.
6. Setting up Git locally is a breeze, so it’s easy to use anywhere you want to manage a changing document… for example that novel you are writing about a fictional small engineering company.

Things about Git that I’m not crazy about:

1. If you get a conflict while updating, it’s not as easy to choose “theirs” as it is with svn.
2. There are one or two operations whose locations or syntax don’t make sense to me.  The developers could have chosen more wisely.
3. Git has some tools that are dangerous in that it is possible to screw up and lose data and/or history.  I suppose that’s true of any revision management system.
4. There is one feature that I call a bug that seems to involve a time-out.  It comes up only in very specific circumstances, but I’ve hit it a couple of times.

I also use Git for some other special activities.   Since I have a desktop and a laptop, I have the issue of being able to start work on one machine and then continue on the other.  There are a number of ways to solve the “sync” problem, including using Subversion to hold intermediate work.  My solution was to set up a Git repository on a local server we have in house (very easy to do) which I use to sync work between the two computers.  When I’m ready, I can then I can update the company’s master Subversion repository from either machine.   I did a similar thing when a colleague and I were the only two contributors  to a small specialized project.