Subverted

My experience with version control systems, revisions control systems, configuration management systems or whatever you happen to call them primarily consisted of Perforce while at Liberate/TVWorks.  I spent some time dealing with Visual Source Safe before that.  Perforce felt like it was from the future after that experience.

As I moved into more of a team lead and architect role at TVWorks I spent less and less time committing code.  Then Comcast management decided that we should be using common tools across the various entities working on software products for Comcast's video services.  For all intents and purposes this consisted of TVWorks in London, TVWorks in Mill Valley and Guideworks in Radnor.  There are other players, but they didn't seem to be included in the quest to use common tools.  Regardless this yielded yet another change in revision control system for me.  This time the move was to Subversion.  But since I wasn't doing development any longer my experience with Subversion was pretty limited.  Switching to  Subversion made a co-worker of mine was quite excited for some reason, but not because we were using Subversion, but what doing that allowed us to use.  Git.

Upon him explaining Git and taking some time to read up on the tool myself I decided that my interactions with Subversion would be through a Git front end that my co-worker had told me about.  Doing so proved quite problematic for me due to a number of non-standard repositories I had to interact with...also the rather bloated size of the repositories made Git choke more than once while using Cygwin.  I had more success natively on Linux, but still working with git-svn and the CableLabs repository structure was a real pain and I'd generally opted for the script they'd created to complete a sparse checkout of a branch.

As such I became familiar with Git and its interface to SVN, but not really proficient at either one.  We decided to make use of GitHub and a private repo for our code at Redshirt Labs as well.  This also allowed me to learn quite a bit more about Git and the work flow it allowed you to use.  Although my interaction was pretty limited again since my role within Redshirt Labs was more about getting all the other partners to focus long enough to produce our application than doing a lot of application development myself.  I drove meetings, worked our agenda's, found someone to do the creative work, helped limit the initial feature set and set milestones.  Not much development there.

Nowadays I'm getting right down to development once again.  I've been working hard to make Zengaku a universal application that can run properly on both the iPad and the iPhone/iPod Touch.  I've been figuring out how to manipulate the interface to handle orientation changes and creating a lot of new artwork with a lot of help from my sister-in-law.  The point is I've been getting quite familiar with Git now and really liking what I see.

At my day job, or at least on the project I'm working on, we use Subversion.  Once again this is actually working with Comcast and CableLabs coincidentally.  I'm still trying to figure out the best ways to make git-svn work in this situation.  In part due to the Big-Ass-Checking problem I've had.  Using Git and a local repo that I can checkin to makes me feel a lot better while I'm developing and is generally pretty quick to work with.  However the crazy SVN layout still gives me loads of trouble.

I've also learned a few new things about SVN that I didn't realize.  Apparently you can swap branches in SVN like you can in git.  This was totally news to me since it was a big reason why I liked working with Git.  I'd never seen any tutorial or blog talking about this particular feature of Subversion.   Apparently all you need to do is call: 'svn switch'.  You have to specify the URL of the branch you are switching to so it isn't as nice as: 'git checkout <branch>'.  But it would do the job.  I've tried it a few times and it does generally work, although it has failed mid switch more than once...trying again allowed it to complete.

I also learned that SVN is more efficient than I'd been led to believe in that creating a branch is a very inexpensive operation.  It is more akin to creating a soft link than creating a new branch.  This has some problems for me since the branches that are created end up just being complete copies of the entier repository which seems less than ideal since you have a large amount of code that has nothing to do with what the branch is about a lot of the time.  In particular when we are talking about the CableLabs tru2way repository.  The other thing I didn't realize about Subversion is that when you merge change from a branch back to the main or trunk you lose the individual submissions that got you to that point.  Unless you keep the branch around (which you could, but would make for a rather wild tree after a while).   When I found this out it really made me scratch my head since at this point I'd though that since Git didn't have such a problem, subversion surely wouldn't either.  But as my co-worker pointed out...I kinda jumped the queue and when straight to go collecting my $200 with Git.  I never really had to live with Subversion so I just assumed that the Git way was the way things should be done.

This was a bit of a meandering post that ended up way, way longer than I thought it would.  But I'm going to share it anyway.  Hope someone findes it interesting and maybe finds out something new as well.  I might talk more about how I'm managing to use Git in our current environment in a later post.
There was some chatter that CableLabs might be considering a move to Git, but I'm not really hopeful.  Although it would definitely make my life a lot easier.