Balancing software engineering best practices with the realities of being a student (and thus often working alone or in very small groups) is a bit tricky, particularly when it comes to source code management. I know that it’s a very good idea to use some sort of version system, I’ve been told this by my professors time and again, and I’ve learned it the hard way myself.
I remember one particularly frustrating incident where I made changes to various (unversioned) files and then decided I wanted to revert to a particular state, only to spend the next hour or two trying to figure what, exactly, that state was. After that, I decided that I would always use some sort of source control system for all but the most trivial projects.
Wherein I try Subversion
Of course, this turned out to be something of a trial in and of itself. Not knowing much about SCM systems at the time, I turned to what I heard the most about (namely on Slashdot…). At this time Subversion was becoming the “big deal,” and nearing a 1.0 release. So I decided to give it a try. It works well enough for me that I still use it to this day, although I’m becoming more and more annoyed with it.
Time: Passes; Time: All Wounds Heals
So this was several years ago that I opted for Subversion for the wonderful reason that it was popular. In the intervening time I had some exposure to other systems. For instance, in the Software Engineering course we used CVS extensively, and I came to truly and fully appreciate the work of the Subversion team. Additionally, the professor who maintains the Math/CS divisional servers and sponsors the local Linux User Group discovered darcs and sparked a fair bit of discussion, both in the LUG and amongst the CS student body as a whole, about distributed development models in general.
An Aside Regarding Centralized and Distributed Development
While the two basic models of development have been understood for years (that is, the Cathedral and the Bazaar) it is only recently (at least to the best of my knowledge) that development tools have really started to diversify along the same lines. In particular, version control systems have split into two basic categories, those focusing on centralized development, and those focused on distributed development (of course these aren’t truly mutually exclusive, one tool can do both, and one workflow can actually accomplish both fairly readily).
The centralized tools, like Subversion and CVS, are organized around a client-server model. There is a single storage location for all project history and individual developers have local access to, at most, their changes and the version upon which those changes are based. This works just fine in settings where developers are always connected and there is a central authority managing the code.
However, in disconnected environments, or with projects along the lines of the Linux kernel, where there is no true central authority, this model doesn’t work so well. To address this issue more distributed version control systems have been developed, for instances, darcs and Bazaar. These tools generally give the individual developer his own repository, stored on his local machine. He then develops against this, committing changes to it as needed. Then as needed those changes can be pushed to other developers or some upstream source, if it exists.
Returning to Our Story
So having been exposed to another way of thinking about SCM, I start to wish for certain changes to Subversion. To better illustrate this, lets look at my work environments:
- First, when I’m at my apartment I work using my desktop, a system running Windows XP (and Cygwin, so I can also use UNIX-y tools if I need to). This system has a permanent, fast ethernet connection to the server where repositories live.
- Second, I like to get away from the apartment at times, so I’ll work with my laptop, a system running Windows Vista (again with Cygwin). Provided I can get wireless access, I have a slow, flaky connection to the source code repositories via residential DSL. Unfortunately, some of the more interesting places to go around here don’t exactly have wireless access.
- Finally, there’s a nice lab on campus for math/CS majors only (we call it the Nerdery (-: ) and I like to work there, particularly on group projects. The systems there are a mix of Windows XP, OS X, and thin clients that connect to the communal Linux servers. Of course, from any of them it’s easy to shell or VNC to those same communal servers. But, again, I have the problem of repository access over a poor quality connection.
At first glance it looks like a distributed system would be ideal. However, I actually like certain aspects of the centralized approach–namely that there is a central, authoritative repository. I don’t need or want a system so distributed that I have to go through anything beyond an update to get my latest changes. Also, most distributed systems are designed primarily as command line tools, and if they have GUI components they’re built for Linux systems. Now, I can handle that, if I have to, but I rather like TortoiseSVN (an interface for Subversion that integrates with the Windows shell) and I’d like to have that with whatever system I use.
As it stands I don’t have a good solution to my dilemma. However, Bazaar looks fairly promising. There’s a plugin for it that allows transparent branching/merging with Subversion repositories, unfortunately it’s pretty much impossible to get it working with Windows right now, as it requires either a development version of Subversion or a patched version the 1.4.x tree. Additionally, there is no Windows shell integration for Bazaar–yet. It looks like they intend to create that fairly soon. I hope.
