CS 50 Software Design and Implementation

Lecture 4.5

Subversion Version Control (SVN)

In this lecture, we discuss Subversion (SVN) – one of the most commonly used version-control systems for managing source code for project teams.

We set up a local directory called labs and create subdirectories for each of the programming assignments: lab2, lab3, lab4, lab5, lab6 and lab7. We will import our code into the repository as a means of submitting assignments, but more importantly, we will get in the habit of using svn as a back up for our local code – in the case we delete files, we can easily recover them – assuming we update the repository after editing files or adding new files. It is simple and safe so use it.

Goals

We plan to learn the following from today’s lecture:

• How to manage a large number of source files when different people are concurrently working on them;
• How to use svn;
• How to import a source tree;
• How to checkout a source tree;
• How to check for changes;
• Updating a file and doing a svn update;
• Adding new files into the source tree;
• Committing the changes to the svn;
• Restoring files that are accidentally deleted locally; and
• Doing a log and diff against the local tree and the repository.

Source code control - why you need it

When you move beyond a simple assignment, small code set, and toward large, more complex source trees with multiple people working on the source code in parallel— you need:

1) to manage changes made by the group

2) to avoid conflicting changes

3) to track changes in the code

If you don’t use a source code control tool life can get very complicated so let the software tools help.

There are a number of source code control tools:

1) CVS - Concurrent Versions System

2) SVN - Subversion

3) Git - Fast Version Control System

My notes are incomplete here. But I want to capture the various scenarios for svn that I went over in class. Note, Wayne keeps FAQ on svn—check it out; It’s also recommended that you read the online official tutorial available at http://svnbook.red-bean.com/en/1.5/svn-book.html , especially Chapter 1, which introduces the fundamental concepts of version control systems, and will help you better understand how svn works, and Chapter 2, which is a superset of the tutorial above, covering more svn commands—but the notes below should be sufficient for you to manage your svn account.

Also, checkout the following howto for use of common svn commands: http://www.abbeyworkshop.com/howto/misc/svn01/

SVN Example of Lab 2

Your svn repository root is at https://svn.cs.dartmouth.edu/classes/cs50-S12/yourlinuxaccount We will introduce the basic usages of svn by walking through a simple example.

NOTE, in the notes below change cs50-S12 to the correct year and term for example W12 changes the svn commands below to cs50-W12. Also, you need to use your full DND (also blitz name) and password (Blitz password) and NOT your CS account name and password).

Notice below that we have a a directory for all our labs called labs with subdirectories for each lab. You should do that; that is, create a top level directory in your home directory called cs50; then create a subdirectory called labs. This subdirectory will have a subdirectory for each of the assignments.

Assuming you complete the coding assignment (or for that matter started written some source code – that is you shouldn’t wait to complete all the programs in lab2 before you use svn).

First thing we want to do is to import the lab2 source tree for the first time into svn account. Note, you want to replace “campbell” with your own linux account username.

We import lab2 to repo under project campbell/lab2.

Also note that I have changed my PS1 prompt so you can see which directory I am in. This is important when you are issuing svn commands.

Note, you can also just point your browser to repository and look at your code. But I recommend just using the command line interface for this course. So I could click on: https://svn.cs.dartmouth.edu/classes/cs50-S12/campbell/

The complete lab2 source tree is now signed in. (If you do not want to be bothered with the ATTENTION... message any more, You can carry out the suggested changes to the svn configuration file as suggested. I wanted to avoid having to type my password any more, so I allowed password caching.)

Only a working copy will have a .svn folder. Import doesn’t create a working copy which means this directory is still NOT under version control.

To create a working copy, you must use checkout first.

OK, let’s sign out the complete source tree for the lab2 source tree into the same directory. But first remove the local directory. You might want to make a local copy because we are about to delete the directory with all its files in! We will then checkout the files stored in the repository to the new lab2. After that the directory and its checked out files are under source control.

Note, you need to checkout a directory before it is under source control.

OK. Let’s edit spy.sh locally and run status again. The “M spy.sh” message indicates that the local version of spy.sh has been modified.

Now let’s commit our new changes to spy.sh to the repository - for example Alan might need my new file for his build. svn tells me that the spy.sh file has been committed and has a new revision: 65.

Say we want to add wget_count.sh to our repo; that is, we add a new file to the local directory and now we want the repo to mirror it.

Imagine that we accidentally removed some files that we didn’t mean to; it is very easy to get the locally deleted file back from the repo – this is very handy. We will use the update command here.

But if we really want to delete a file from svn, use svn delete:

Other useful commands include svn log and svn diff.

Finally, svn diff is useful for seeing if there is any difference in the tree.

The information below is for Andrew. You need to delete the lab2 directory in the repository and remove the .svn file before starting this lecture. Students, ignore this: