Blog 3: Subversion and Source Control


This blog is all about source control and Subversion and before I approach them in its whole context I consider it necessary to define some key concepts like repository, workspace, and mainline. By now it is a common practice to add, update and commit our source directory and source files without too much concern of where all these changes are actually happening. The magic lays in something called repository. A repository is all the project files (both old and new versions) stored in a reliable and safe computer which acts as a server. Okay, but how do my partner and I get access to those project files in order to distribute the project's workload between us? In that case we have another place called workspace. The workspace is a local copy of utilities and code that we need from the repository to work on our part of the project. In order to retrieve copies of those files out of the repository into our workspace, we use the command checkout. The command checkout brings to my mind a situation where I could not understand why the file "translator.cpp" was being skipped when I was updating the /src directory. The textual message was like this: "skipped translator.cpp". As you know, it is not possible to run any test without that file. So, I erased all the files, I update the whole /src directory, and I got the same result over and over. Finally, I asked the TA Shi Bai for advice on this issue who suggested that I should check out my workplace one more time just to see if it fixed my problem. He was right about it, if you pay close attention to the purpose of checking out, you will realize that this command populates your workspace with up-to-date copies of the files you request. Mainline is an useful concept in terms of visual perception, you can image a horizontal line that divides in many branches and each branch is running the same project in different scenarios or stages that later will merge in only one improved project.

Now that all of us have a clear understanding of the three key concepts: repository, workspace, and mainline, I will be able to describe some version control commands that I believe all of us have used very often in the lab assignments. Okay, let me list them: add, update, commit, status, diff, log, and resolved.
svn add: I use it every time I add a new directory, e.g., lab1, lab2, etc. or a new file, e.g., scanner.cpp, parser.cpp, etc.
svn update: I use it every time I want to check my partner's changes in the project files.
svn commit: I use it every time I want to save my changes back to the repository.
svn status: I use it every time I want to see if one of the files has been modified. I remember one time I used status for "translator.cpp" and I got a message stating that the file was not under version control.
svn diff -rHEAD: It is very useful to be sure that you agree with changes in your local copy file versus the current version in the repository before you update it.
svn log: I use it to look at the history to see who committed the last changes in a file in case a conflict arises from output between my partner and I.
svn resolved: I use this command to tell Subversion that the conflict of output has been resolved.

Subversion belongs to the second form of conflict resolution called optimistic locking. Optimistic locking allows every developer to edit any checked out file. However, if you want to check in any changes in a file you will have to update first your local copy to include the latest repository changes before checking in. Then, the version control system attempts to merge the repository changes with your changes. A conflict arises when two developers edit the same line of code. In this case both developers have to decide whose change should be included in the repository. In reality, developers rarely work in the same file in the same line of code. I remember from Lab 3 part of the assignment was to create a conflict where my partner and I were modifying the same line of code. At the end, we resolved the conflict using the command svn resolved.

As you can tell, Subversion is a powerful version control system which allows developers to feel free to change code, update code, erase code at anytime, anywhere without worries. However, according to Andy Hunt and Dave Thomas, close to 40 percent of project teams in the US don't use any form of version control at all ("Three Legs, No Wobble", 2004).


While its true that developers are rarely working on the same source code at the same time, I've found that it can cause problems when people reformat or "fix-up" your code written by another author. This is the most common cause of conflict I have with most subversion projects and can be somewhat of a pain to deal with at times.

svn add, update are used usually once when we work on project or lab, but I use commit many times for showing my work to my partner as much as I can. I also remember lab 3. My partner and I did something wrong, so it took long time to solve.

Nice touch, referencing the paper.

Caleb Ahlquist

Very good work. I like how you really laid out step-by-step each function of subversion and what each function does.

Leave a comment

About this Entry

This page contains a single entry by ayal0034 published on October 27, 2011 3:12 PM.

Blog 2: Working in Groups was the previous entry in this blog.

Blog 4: Testing is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.