The Pros and Cons of Source Control via Subversion

When working on a software project, you would often like a way to organize your project files and be able to access them across different platforms. When working on the project in a group, your situation is further complicated when all of your group members are updating files for the same project. Without any means of organization or backup, each person will be editing files and perhaps overwriting important code made by other people. In addition, once those changes are made, there is no way to reverse them. If one of your team members takes a functional program and creates a faulty one from it, the entire program is in jeopardy. Source control is a means to solve many of these issues and is especially useful in a group setting. I will discuss with you my experiences with Subversion, a form of source control, and explain its advantages and disadvantages.

When I first started using Subversion at the beginning of the semester, I found it to be a cure for many of the file management headaches that I had encountered previously when working on computer science projects. I confess that I had never even heard of source control or Subversion before and the idea behind them was truly revolutionary to me. Now, for the class project I could "commit" my progress to the repository and my partner could then access the updated files instantaneously from anywhere. The need for the two of us to sit down and work on the project together was almost completely gone. Also, Subversion would automatically "merge" any progress that the two of us had separately made and notify us when we had both edited similar portions of the project which could potentially result in a "conflict". We also did not have to worry about messing up functional code because now we would have a way to undo any potential damage that could have been made and thus we would be able to do more "experimenting" with our code. Furthermore, I did not even have to be connected to the internet in order to work on our project. We each had our own "workspace" on our computers that allowed us to work on the project from anywhere. The only time we needed to be online was when we were updating our workspace and committing any changes we'd made.

Thus far I have made it sound like source control cured all of the problems that were associated with doing software projects. However, this was not the case. Firstly, when I began using source control for Iteration 1, Subversion did not even allow me to commit to the repository or update any of the files on my workspace for reasons that were unknown to me at the time. By the time I had figured out the issue (which involved going to Professor's office hours to get help), Iteration 1 was nearly due. Due to this, my partner and I resorted to email as the sole means of communication and file transfer for most of this iteration. This example highlights a couple obvious flaws of Subversion. The main reason I was having trouble was that I was not familiar with all of the commands of Subversion and how to properly read the feedback Subversion gave me. Thus, I learned the hard way that Subversion requires a fair amount of training in order to be used effectively. Most of the problems I encountered were relatively simple in nature and it was just that I had not been told (or more likely had not remembered the TA telling me) how to do all of the commands. One of the more trivial problems I encountered was the result of me not realizing that I needed to "add" files first before committing them and thus this resulted in errors. Also, I did not know that having extra files that I did not want to put in the repository in folders that were to be committed would cause issues when attempting to commit. This brings up another flaw with Subversion. If there are errors related to Subversion in the files in your workspace, many times you can neither commit nor update at all until the problems on your workspace are solved. In Iteration 1, this fact resulted in me not being able to upload perfectly functional files due to problems related to other files in my workspace. I realize that there might be reasons that Subversion is implemented this way but in my case, I don't understand why I was not allowed to commit good, error free files.

As I have shown, source control, in particular Subversion, has some obvious flaws but I firmly believe that the problems that it solves far outnumber the problems it creates. Not only can all people involved in a software project be able to access the most up to date code and then modify and commit any changes, but they also can undo any changes that had negative consequences. Furthermore, there is not as much need for programmers to be physically in the same area since the most up to date copies of project files are available anywhere there is internet access. All in all, source control, if you know how to use it, is a very important part in any software project and can reduce or eliminate many of headaches typically involved in those projects.