Encoded

I am in my last week at my current job. It’s time to check-in all the little projects and tweaks that are currently unfinished, or not ready for prime-time, into Subversion. My main concern, like that of any conscientious developer, is that I don’t totally pollute the head of the main repository with tweaks the rest of the team may not want to implement for days, weeks or ever.

I pulled out my SVN manual (svn help via Terminal) and started hunting for the perfect command. I needed something that would allow me to change my current working repository to a branch in the same repository. I have never needed to do this before so it was definitely going to be a learning experience. 

There are many svn commands, I count 30. My favorite is ’svn blame’ though I have never had the opportunity to use it, I just love the name. 

I found my command, ’svn switch’, and ran ’svn switch -h’ to get more information on it. You can find the same info here. I found exactly what I was looking for:

Update the working copy to mirror a new URL within the repository. This behaviour is similar to ’svn update’, and is the way to move a working copy to a branch or tag within the same repository.

Simple enough, I just needed to switch over to the branch and check-in my changes. Sadly, it didn’t go down quite that easy.

After I ran the ’svn switch’ command, svn stopped abruptly and complained that one of the files I had in my working copy had been deleted from the main repository. To verify this I checked out a totally separate instance of the project and discovered that the file had been deleted then restored in the same location with the same name. Subversion was unable to comprehend this and threw an error.

To verify if the switch command had been successful, I ran ’svn info’ in the root directory of the project and the other folders I had been making edits. I determined that the switch had been successful. The URL indicated my branch, which seemed reasonable, so I proceeded to check-in my files.

Later that day, a co-worker was getting ready to push a few small enhancements to production and updated his working copy only to find all my minor tweaks and edits polluting the head, and now his working copy. Holy crap, that’s a problem! I knew I had switched to the branch, so how had my changes magically shown up in the head of the repository?

I began combing the repository history and also searching on Google. The command I was using, ’svn switch’, runs as recursive by default. Plus, I had verified that the subdirectories’ URL had changed to the branch. After I restored the trunk to the planned and wanted revision, I took a deeper look at the problem.

It turns out that Subversion had switched many (but not all) of the folders to the branch. Also, it had not switched many of the files to the branch. Parts of my working copy were pointing to the trunk and parts of it were pointing to the branch. While this is a fairly cool and useful feature of Subversion, it’s not what I wanted in my situation.  

What I found even more perplexing is the files that had been switched to the branch were in no particular order. It was definitely not done in alphabetical order. I ran ’svn switch’ again on my working copy, which caused a little more confusion because files that had been commited into the trunk were now being deleted out of the branch. It was a fairly frustrating experience. Even more disappointing, this is not the first time myself or a co-worker has been burned by SVN.

At my next job, which is also an SVN shop, I plan to take a look at Git. I have looked at Git in the past, but because I was working in CVS or SVN shops, it seemed to painful to switch. However, a peer got me very excited about Git after running down some cool features. He also told me that Git has an SVN sync feature,  so you can use Git locally and still sync with a global SVN repository. I will save my experiences with Git for another post.

What’s your favorite revision control system?