Sauce Control

Source Control is an important part of the daily programming grind. Every morning we wake up, brush our teeth, and head on to other daily activities. And every afternoon we might continue the constant process of committing our changes and updating to the latest version of our code. But what are these two things I have already mentioned, Committing and Updating? And which source control method are we even talking about?

You can read a concise history of Subversion here, but essentially, a previous sauce control schema called CVS lacked in certain features and a few developers let out to create a new system.
svn checkout — Check out a working copy from a repository.
This is the first thing one does when working with a repository of code. You check out a copy for making changes. Now how do you put those changes back?
svn commit — to send changes from your working copy of your own version of the code to the repository.
SVN's best feature is the ability to work on a shared code base. This code area is called the Trunk. The Trunk is where the full copy of your code lives all time. When one commits code to SVN they are adding their changes to the trunk.
 svn update — Update your working copy of the code from the repository.
Updating will bring the latest version of the code from the repository to your machine. From that point the developers using the repository can make changes to the updated versions and then commit those changes to create a new, updated version of the code.

These two features are great but lead to one issue. If two team members are working on the same file, make changes to that file, and then try to commit, they will hit a snag because of an out of sync code base. Luckily my team has not had this problem yet. The process can be resolved with what is called a merge.
svn merge — Apply the differences between two sources to a working copy path.
A Merge is when a developer looks at the changes to his/her local version of a file and the changes made to a Trunk file that hasn't been updated on the local version, and fixes the synchronization issue by amending the code to include both updates or one of the updates. There are 3 possible outcomes of this process.
  • Override and Update: In this case, the local version of the file is discarded and the Trunk code overwrites everything. 
  • Override and Commit: This is similar to Override and Update, but the Trunk code is overwritten with the local version.
  • Merge Changes: In this solution, both changes are merged into the local version and (s)he is able to commit the file and overwrite the Trunk file.  
Now you might ask, "How am I supposed to know what the differences in the files are?" well SVN has a command for that too.
svn diff  — Display the differences between two paths (files).
During the process of Commiting, Updating, and Merging, the code base can change quite drastically.  If a problem arises, backing up your data is key to continuing a project without major losses.  SVN provides a way to backup your code via Tags.

A Tag is a snapshot of your code at a given time.  It is similar to a Trunk but it is assumed a Tag will not change in the future.  This is useful if a situation arises where it is necessary to revert your code base to a prior state.  In larger environments, Tags are created with each build. Version 1.0, and so on. Luckily, we have never had to revert back to a tag yet in our project.

Just in case you need to offshoot your code for some reason, say to introduce a new developer to your code, and you don't want them working in the Trunk, SVN has something called Branches, They are a separate Trunk-style project used for work on the project.  Branches can be created from existing code bases, including the Trunk and Tags.  Even better, you can Merge between a Branch and the Trunk to bring in changes from the temporary project that need to be implemented into the code base.

For full technical information on command syntax and even more in-depth information. http://svnbook.red-bean.com/


  1. You have an interesting way of writing. Although I disagree with the way you compare Source Control with the general life style, The way you format your writing style and explanation of SVN draws a lot of attention, It simply make reader want read further.

    Edem C Sessou

  2. Very well written, it seems like you copied this out of a manual...a few searches indicate that you did not. Nice job, good info...the world needs technical writers. I might add some of SVN's imperfections, though.

    Graham Smith

  3. very interesting writing. But I guess people would like to read the svn --help more about how to actually use subversion

  4. This blog would be super useful if I didn't know anything about svn. You obviously know whats going on with source control software.