Subversion (svn) Lab

In the bad old days, it was difficult to keep track of source code when several people were working on the large project. Generally, a master copy of the source was kept somewhere, and you just had to be careful when you made changes. You had to make sure that Bill’s latest change didn’t replace Elizabeth’s recent bug fix. What if you made a bad change? You hoped that you had a backup tape. It wasn’t a very good system.

In this lab, we will use Subversion, which is a system of source code management. It’s used to maintain the history of software changes (or any other file, for that matter), and to permit multiple developers to collaborate on a large project.

Think of it this way: somebody creates an svn repository, somewhere. It contains a number of files and directories. Often, this will be a large open-source software project. Using svn, you check out a copy of these files (like checking out books from a library, except that this is a copy). You can also:

• view the history of any file
• add files to the repository
• make changes to your copies of those files, and check those changes back into the repository
• retrieve previous revisions of files in the repository

You access this repository in a variety of ways: using ssh, using local file access, etc.

Subversion clients are free, and exist for Windows, Linux, Mac, you-name-it.

Subversion commands are generally like this:

Using a remote svn repository via http

First, we will use svn to examine the svn repository that holds the source code for the svn command itself. These operations may be slow, depending on how full the intertubes are at the moment.

1. Make an empty directory somewhere
2. cd into it
3. Check out a small subdirectory of the svn repository:
   svn co http://svn.apache.org/repos/asf/subversion/trunk/doc/
   This will create the directory doc, which will contain a number of files, and another directory.
4. cd doc
5. ls -l
6. See the history of the file README:
   svn log README | more

Using a local svn repository

Let’s use a local svn repository, for the sake of speed. I’ve created one in: /s/bach/a/class/cs253/pub/svntest
(Instructor, recreate ~cs253/pub/svntest/ from the tar file ~cs253/pub/svntest.txz if needed.)

1. Make a different empty directory somewhere
2. cd into it
3. Check out the repository:
   svn co file:///s/bach/a/class/cs253/pub/svntest/calc
4. cd calc
5. ls -l
6. svn log README

The instructor will now change a file in the repository:

• Make some change to README
• svn diff README
• svn ci README

Now, everybody update their own copies:

• svn update

You ought to see something like this:

U    README
Updated to revision <number>.

Notice how you haven’t had to specify that awful file:///s/bach/... path since first checking out the repository. That’s good.

What about conflicting changes?

When you do svn ci, it will attempt to check in any files that you’ve modified. If somebody else has changed the repository version of that file after you checked yours out, then svi ci or svi update will give you an error message, and present a number of options.

With the help of a student, the instructor will now create such a situation:

1. Student does svn update
2. instructor does svn update
3. Student changes a file, and does svn ci
4. Instructor changes a file, and tries to do svi ci.

See http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.resolve for more information on how conflict resolution works.

What else?

There are many aspects to svn that haven’t been covered. Do svn help for an overview, and svn help subcommand for information on any of the svn subcommands. Some of my favorites:

• svn blame filename
• svn add filename
• svn delete filename
  (Don’t be a jerk—only delete what you added.)