Get Control

Writing code can be a difficult process and figuring out how to handle all of that code can be difficult as well. Luckily, there is a solution to the latter in the form of source code control, or version control. Different source control systems exist but one popular version I've used is called Subversion. Two of the best benefits to source control are version record keeping and the sharing and merging of code. The former benefit allows for time traveling of the development process to a stable time before problems arose as well as describing of changes made to controlled code over time. The latter benefit allows for teams to easily work together on projects by distributing and updating code to each team member in a simple manner. Opponents of source control may say how source code control can lead to more headaches than benefits but these headaches aren't always the fault of the source control system. Before we go into the benefits and opposition of source control, let's see exactly what the system does and how to use it.

Source code control works by implementing a server with a repository where team member can share their code and other related materials with other team members. In addition to having the files on the server, team members have a local copy of the repository to work with on their own computers. Each team member can do various tasks with the repository server including retrieving new files, updating local copies of files to what is new in the repository, pushing updated or new files onto the server for others to retrieve and viewing the lifetime of a file on the repository. Subversion users can execute these tasks through simple commands in a terminal. They can "checkout" a repository when first beginning their use of source control of a project to initialize their workspace, or local copy of the repository. From there, Subversion users can "update" within a directory under version control in their workspace to obtain updated files from the server. Users can also "commit" changes they have made to any files under source control in their workspace to the server and increment the revision number used to represent the version the repository. (Users must first "add" any new files and directories created to Subversion before they can be committed to the server). But of course, why have version controlling if you can't determine differences between various versions of files? Users can invoke the repository server to display a "log" pertaining to the revisions of an individual file or directory or even the whole project. These log entries include information pertaining to the revision number of the entry, who committed the changes, the date and time of the commitment and any comments written by the team member who made the changes. Users can even invoke a "diff" to determine what changes exist between the different revisions of a file or "revert" a file from their working copy to different version that had been previously committed. Performing any of these useful tasks can be done with just one command in a terminal which allows for easy learning of Subversion. It's no wonder that with all of these commands that Subversion and other source control systems allow for great benefits.

One benefit to source control systems are their time traveling qualities. Two reasons for wanting this benefit exist. The first reason is that people make mistakes and we computer scientists are just as vulnerable to this as anyone else. The second reason is that requirements change. Take for example a situation that happened to me recently while working on my current project for CS 3081 where both of these reasons for needing time traveling came into play. My partner and I implemented the use of a certain data structure prior to it becoming a requirement for our project. Unfortunately, the way we had originally implemented this structure was different than what our new requirements wanted. Having made many changes to our code to conform to requirements and having run out of time to work in the computer lab during discussion, we committed our work from one machine onto the server to continue our work later. However, when testing our new code a short while later, we discovered a few fatal errors existed. By using the "log" and "revert" commands of Subversion, we were able to quickly restore our files to an earlier revision and begin our work again on a different path that lead us to success. (A note to new users of Subversion: use descriptive comments when committing changes so that the log kept by the server is helpful in showing you what the best revision to revert back to it.) Of course, this record keeping is not the only benefit that users to source control experience.

Another great benefit to source control is the ease of collaborating with a team due to easy sharing and merging of code. As I've already mentioned, retrieving updates from the repository server is just a one line command and so is committing changes to the repository server. In the past, I've used some methods to sharing files that look horrid in comparison such as emailing new files to a partner. With using Subversion, I simply commit changes onto the server and let my partner know to update his copy of the files when he gets a chance. But what if multiple team members work on the same file and all commit those changes to the server? That is no problem and should even be encouraged! Pulling from my own experience during the first iteration of the CS 3081 project, I'll show how useful Subversion can be in this case. While developing a large function, my partner and I split the work. We worked on the same revision of the file and each committed our changes. Subversion caught on to what we had changed and merged our changes together into a single file, even though what we both committed looked different from each other. Now instead of us simply adding lines to a file, what if we both changed the same line of code? Well this actually happened once and Subversion was not able to merge the files. When the second person was committing their change, Subversion pointed out our conflicting file contents and gave us several options on how to resolve the conflict. Once we chose the resolution method needed, Subversion took over and completed the merge on the server's repository. Opponents to using source control may cite the problem we experienced as a reason for not using such a system.

Due to the extensive automation performed by source control systems and the learning curve to use them properly, opponents to such systems feel they are a bad solution to managing code. I'll admit that early on in using Subversion, I didn't trust its merging automation and I even used the merging conflict mentioned before as a backing for that belief. I had blamed Subversion for the inability to merge and it wasn't until after examining the cause of the conflict did I realize the problem was human error, not source control error. My partner and I realized our miscommunication on what each of us was to edit was the root of the conflict. In retrospect, I'm glad Subversion discovered this because it was a way of showing a logic error in our development process. In addition, to successfully use a source control system, the user must learn many aspects to their system including what revisions represent, how to first get started with the system, how to add and commit files, how to update files, and how to get in the habit of keeping their workspace up to date. Learning all of these aspects is not difficult if you use an easy version control system like Subversion, but I will agree forming habits of proper workspace maintenance can be difficult. However, these problems lie with the user, not the source control system. Someone who can't get into the habit of committing new code the repository likely isn't in the habit of taking the time to manually copy files they have worked on to distribute them to team members whenever they make changes. Once it is clear the human element should not be considered a strike against source control systems, it is clear there is little reason not to use them.

As I've shown, source code control systems, such as Subversion, make the lives of programmers easier. These systems allow for teams to track changes during development and to turn back the clock when problems arise either due to mistakes or changes in requirements. In addition, version control eases the distribution of code for a team by providing a single server to commit changes to or to extract updates from as well as intelligently merging changes of files. Some programmers dislike source control systems but when looking at some such reasons, it is apparent that the human factor is to blame, not the system. I'd highly recommend the use of source control systems for any serious programmers.