I’ve been using Subversion even as a single developer for several years now. It’s invaluable to me and millions of other developers. If you’re a developer working on any project that lasts more than a couple hours and you aren’t using version control then you are shooting yourself in the foot. As a developer, we’re comfortable with juggling several things in our heads at the same time, it’s a fundamental skill we use everyday when developing software. But when you start to do ‘internal’ version control in your head while developing you are only slowing yourself down and it will ultimately lead to lesser quality code.
Don’t think you’ll need this chunk of code, but you’re not absolutely sure? Did you just rewrite method X but you want to keep the previous iteration around as a reference? And more relevant to me: Are you making a bug fix but are mentally keeping in mind how to revert that fix in case it doesn’t work?
All of those questions are red flags that you aren’t using your version control system (if any) to a meaningful capacity. That last question came up earlier this week when I was wrapping up the first alpha build to start testing with a small group of testers for my iPhone game, Tilt To Live. I wanted to implement a new collision algorithm in the game so the higher difficulty levels would run much more smoothly. Wanting to get this right ‘the first time’ (hahah ya right, another lesson learned) I first mocked the algorithm up in Blitzmax, optimized there and debugged it there. Of course, any debugging done in a different language for a mock up is fixing purely conceptual bugs rather than implementation bugs.
The Wednesday night deadline was quickly approaching and I just finished implementing the new algorithm. I start play testing for 5 minutes. 10 minutes. 15 minutes. 20 minutes, wow the game is performing really well! 25 minutes, CRASH! WHAT?! How can this be?
So I quickly restart the game to see if I can figure out any clues as to why it is happening. 5 minutes in I crash again, but it’s still seemingly random. And the debugger isn’t spitting out any useful information to help pinpoint the bug. Knowing the only code I had introduced was replacing a call to the new algorithm I knew just replacing a single line of code would revert me back to the ‘previous version’ (this should have been red flag #1). I start debugging for hours to try to find the cause of the ‘BAD_ACCESS’ fault that is most likely coming from a null pointer somewhere in the new collision algorithm, that seems to still happen ‘randomly'.
Anyway, hours pass and then the next day I spend a few more hours on it to try to see if I can fix it before I start trying to compile an alpha build. Failure. I simply just need more time to get this fixed without releasing the alpha build with a critical bug (red flag #2).
In the end, I had to revert to the slower n-squared collision algorithm for the alpha build. Using SVN, it was trivial to revert back to the previous version, quickly test it, build, and release. Yet, there is a much better process to avoid this very time-sensitive issue of getting bug fixes into a build without compromising the stability of the build. It’s called branches.
Now, I’m no stranger to branches, as I use them to catalog releases, but to incorporate them into my daily development routine is new and is something I’m going to try to implement to avoid this issue in the future. Jeff Atwood, co-creator of StackOverflow.com, has a rather good summary of different branching patterns for on-going development. As a single developer I’m going to try to adopt the ‘trunk is sacred’ **(****Branch per Task)** method and try to merge features into it from development branches.
What’s the benefit? Always being able to release something that is relatively stable regardless if you’re in the middle of something or not. And you don’t have to worry about ‘auxiliary’ changes you made leading up the current fix that may also break the build. I’m finding that as I draw closer to a more complete game, I need to be able to release builds on a weekly or bi-weekly basis for testers to play test. Knowing that there is some glaring bug that is a showstopper is a head ache for you and your testers.
I’ve been researching different version control systems outside of SVN to see if there’s something that could make branching and merging more seamless and integrated into my work-flow. I’ve found that distributed control systems such as git, and Bazaar, supposedly make this fast and easy. Although, I’m not ready to give up subversion yet; mainly because it is working. But I may test those systems out in the future for smaller projects. TortoiseSVN’s merging dialog can be a little more clearer, as it stands now it is rather confusing the first time you use it. I’m currently testing out Versions (Mac Only) since I’m developing mostly on the Mac for the iPhone game, and it seems to be a little more intuitive in branching, but can’t comment on merging yet as I’ve yet to look into it.
And now I’m off to enjoy the rest of my weekend :).
Update: Looks like Versions won’t suit my needs. Neither will Cornerstone. SyncroSVN Client seems to support basic things like switching, merging, and branching while the other more ‘fancy’ looking apps don’t do anything beyond committing/updating/branching. Except that SyncroSVN’s GUI isn’t any easier than the command line for merging/switching. Looks like I’m going to the command line or revert to using Tortoise SVN (on windows) for the time being while these Mac apps sort themselves out and mature a bit…