2 min read

Re-vision

Topics:

As we work towards our next release of Storyboard, we are currently at the point of the cycle that I like the least.  It's the point where we lock down our SVN tree and only allow bug fixes in.  I understand the reasoning.  Huge amounts of code churn before a release are never good.  This does, however, have one drawback.  It means that I can't just take some time and experiment with something, as I can't check it in, and if I need to make an actual legitimate bug in that same source, I would have to revert my changes so that I could check in the fix to that bug.

There are workarounds to this with a subversion repository.  You can check out multiple versions of the repository, or you can work with patch files.  Both of these solutions come with problems however and therefore they limit their effectiveness.  You could also create a branch and work in that branch, but then at some point you have to merge branches, which could be tricky.

Git is supposed to be the answer to this sort of problem.  It's supposed to allow a developer a little more control over what makes it in and what doesn't.  Keep in mind that I haven't had a lot of experience with Git, but the little that I have makes me skeptical that it really is a panacea when it comes to revision control.  It seems to me that you need to have everyone on the same page when it comes to workflow or else you can end up in a world of hurt.  To that end subversion is simple to use, and it provides most of the functionality needed.  It's just this one certain case where it is lacking.  To resolve this issue, is it really worth have to learn a new workflow?  I am not really sure.

- Rodney