CSE 265: System and Network Administration

Lab #12

Originally courtesy of Owen Cummings, Lehigh graduate

FRIDAY's CLASS will NOT be in our usual room. It will be in Mohler 375.

1. Exploring Subversion

   For reference, you might want to look at the Subversion manual or the built-in svn help [subcommand]

   In this lab we will install Subversion, create a repository, import a project and play around with the features of Subversion to get a feel for how it works.

2. Installation

   The first step is to install Subversion on your machine. This can be done (if needed) as usual with yum install subversion.

3. Making a repository

   Now that Subversion is installed, the next step is to create a repository. (Note that most of the following commands don't require root access, you should run them as a regular user.) First, create a directory to contain your repository. Use:

   svnadmin create /usr/local/svn/repos

   for instance (as a non-root user) to create the initial repository layout (assuming that /usr/local/svn/ already exists, and is writable by the non-root user).

4. Adding to the repository

   Now that we have a repository we need something to import into it. Download the source for your favorite program or just create some made up files and put some text in them. Now you have a temporary directory that contains some files that you want to manage with Subversion, so the next step is to import these files into your new repository. The svn import command can accomplish this. For example, if mytree is the name of the local directory containing your files, use:

   svn import mytree file:///usr/local/svn/repos/some/project

   Whenever you commit, Subversion requires a comment detailing what you change(s) you made. You can do this by using the -m option or by setting the $EDITOR variable in your bash profile. You might use a comment such as "Initial project import".

5. Subversion Client Usage

   Now that the project has been imported, delete the temporary directory you created above and create a new one (/home/user/projects/YourProject for example) where you will store the files you will be working on. The reason you just deleted all of the files in the temporary directory was because they weren't being managed by Subversion, so now we want a copy of the files that are being managed by Subversion which is referred to as your "working copy". The command svn checkout is used to accomplish this. Use it to retrieve the latest version of the files in the repository and place them in your new directory. Explore this directory, note the .svn directory, this contains information that lets Subversion know what files you have changed etc. You should never alter this directory.

   Now that you have files, make some changes to them. Now we want to commit our changes to the repository, however we need to make sure no one has updated any files in the repository since we checked out. svn update will update your working copy to the latest version. Now we are ready to use svn commit to make our changes to the repository.

   Investigate the use of some other commands such as svn add, svn status, svn diff, svn revert.

6. Conflicts and Merging

   Next we will try to create a conflict to see how files must be merged manually. Open another shell and create a second directory and check out another copy of the project. Then edit the same file in both copies but with different content. You'll be able to commit changes to one, but the second will tell you that SVN has discovered a conflict. You'll now have a number of options as to how to handle the conflict. Try looking at df to read the differences between the two versions and explore the other options.

   When looking with df or when editing (e) the conflicting file, you should see what are called conflict markers which consist of strings of less than(<), greater than(>) and equal signs(=). These delimit the areas which are in conflict. It is your job to merge the two changes by removing the conflict markers and merge the changes appropriately. Then you can tell svn that the conflicts have been resolved.

7. Subversion Server Setup

   Now we have seen how to access the Subversion repository locally, we want to set up a server to allow for remote access. First check /etc/services to make sure there is an entry for which ports Subversion uses (there should be) and if not add the lines:

   svn 3690/tcp # Subversion
   svn 3690/udp # Subversion

   For this exercise you will either have to disable your firewall or allow traffic on those two ports listed above; you should know how to do this from prior labs. The configuration files for svnserve are in your repository under the path /path/to/repos/conf

   Edit svnserve.conf to set default behavior and passwd to add a user account for someone in your lab session. Note that passwd contains passwords in clear text, so make sure the permissions are set appropriately.

   Start the server (svnserv) as you would any other service. Everything is set up now, so try to have someone in lab checkout something from your repository using something like

   svn checkout svn://IPADDRESS/path/to/repos project/

   Note the new path to the repository contains svn://IP/ instead of file:///; this is because previously you were accessing the repository on your local machine. But now you are using a remote machine and using the svn server on it. Similarly if you were to set up the server using apache, you would use http://IP/ to access the repository.

8. Wrapping Up

   In order to sign the lab completion sheet, you will need to:
   1. Demonstrate that someone can access your repository remotely
   2. Explain for what tasks svn diff and svn status are used.