Subversion (svn) Lab

Chill

Yes, there are newer systems than Subversion. They’re probably better. It doesn’t matter. The goal is to understand how such systems work. They're all essentially the same. Don’t get hung up on details.                 

Description

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 https

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 https://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

    cd ~cs253/pub
    rm -rf svntest
    tar -xvpf svntest.txz

Let’s use a local svn repository, for the sake of speed. I’ve created one in a subdirectory of cs253’s home directory: ~cs253/pub/svntest                 

Everybody, do these steps:

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
• Make sure that your environment variable EDITOR is set to an editor that you like.
  For example: export EDITOR=gedit
• 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. Hooray!                 

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 svn ci or svn 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 svn ci.

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

Create & use your own repository

1. Break up into groups of three.
2. The first student should do these commands to create a repository:

   Command	Explanation
   hostname	What system am I running on?
   svnadmin create /tmp/rep	Use some other name if /tmp/rep already exists
   chmod -R a=rwx /tmp/rep	allow all users to modify the repository
3. The second student should do these commands from another computer to add a file to the repository:

   Command	Explanation
   cd $(mktemp -d)	go into a temporary directory
   svn co svn+ssh://host///tmp/rep	Instead of host, use the hostname discovered above
   cd rep	go into that directory
   date >now	create a data file
   svn add now	add it to the repository
   svn ci now	check in the current version
   svn log now	See what changes have been made to now
4. The third student should do these commands from a third computer to change that new file:

   Command	Explanation
   cd $(mktemp -d)	go into a temporary directory
   svn co svn+ssh://host///tmp/rep	Instead of host, use the hostname discovered above
   cd rep	go into that directory
   gedit now	change now using an editor you like
   svn ci now	check in the current version
   svn log now	See what changes have been made to now

   Repeat until you’re comfortable with adding and modifying files. Use svn update to get your copy of the repository up to date after another student makes a change.
5. When you’re done, clean up: rm -rf /tmp/rep

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.)