Subversion Service

Overview

Subversion is a "source code version control system" similar to the popular CVS or RCS applications. Subversion allows multiple users to work on the same code base and to manage conflicts, merge code, and reproduce the source code as it existed at any point in time in the development cycle. Besides the "typical use" for source control, subversion makes a very good document control system and even has some capability for storing binary file objects like Word documents (though not all the conflict control features work with binary files).

Supported Clients

Subversion Command line Client (Windows/Linux/Mac OS X)

The basic Subversion package is available for all TSG supported platforms. Most modern Linux distributions have binary packages pre-built by the vendor that can be installed. Other binary packages are available from the Subversion download page.

• Subversion Download page 

Linux/Unix Graphical Clients

• SmartSVN  is a graphical shell for accessing Subversion. It uses the command line Subversion behind the scenes, so it requires that you install that package. It comes in a community open source version usable for educational purposes and a commercial version.
• RapidSVN  is a cross-platform graphical shell for accessing Subversion. Binaries exist for Mac OS X and Windows, and source is available for Linux machines with wxWidgets 2.6.2 or newer.

Windows Graphical Clients

• TortoiseSVN is a subversion client implemented as a windows explorer shell extension.
• SmartSVN  is a graphical shell for accessing Subversion. It uses the command line Subversion behind the scenes, so it requires that you install that package. It comes in a community open source version usable for educational purposes and a commercial version.
• RapidSVN  is a cross-platform graphical shell for accessing Subversion. Binaries exist for Mac OS X and Windows, and source is available for Linux machines with wxWidgets 2.6.2 or newer.

Macintosh OSX Graphical Clients

• SmartSVN  is a graphical shell for accessing Subversion. It uses the command line Subversion behind the scenes, so it requires that you install that package. It comes in a community open source version usable for educational purposes and a commercial version.
• RapidSVN  is a cross-platform graphical shell for accessing Subversion. Binaries exist for Mac OS X and Windows, and source is available for Linux machines with wxWidgets 2.6.2 or newer.

• The Subversion command line client can be downloaded from http://subversion.tigris.org or OSX packages can be downloaded from http://www.codingmonkeys.de/mbo/

Terminology

Additional terms can be found in the Subversion glossary

Commit - Apply the changes from the working copy to the subversion repository.
Conflict - A change in the repository conflicts with a change in the working copy, and that must be resolved before the working copy can be committed.
Update - Refreshing a working copy with latest changes from the subversion repository
Working Copy - A copy of the source that has been checked out of a subversion repository to work.

Requesting a Subversion Repository

Students and Instructional Users

Submit a userhelp@cs.uiuc.edu and include the following information:

1. Course Name that the project is for 2. Professor teaching the class 3. Name for the repository which should include no punctuation or spacing other than underscores (_) and periods (.) 4. Brief description of the project 5. NetID's of individuals that need access

Research Users

Submit a userhelp@cs.uiuc.edu and include the following information:

1. Sponsoring Professor's Name 2. Research Group Name 3. Estimated size estimate for capacity planning 4. Name for the repository which should include no punctuation or spacing other than underscores (_) and periods (.) 5. NetID's of individuals that need access

Requests might take up to 2 business days to be processed.

Command line Client Basics

NOTE: These concepts also apply to graphical clients.

Initial Setup

To start using your Subversion directory, you must first check it out (even though there is probably nothing there yet):

svn checkout https://subversion.cs.uiuc.edu/svn/repository
or
svn checkout https://csil-projects.cs.uiuc.edu/svn/repository

This will create a working directory on your local machine. This working directory is where you will edit your files and make changes. It will also create a directory called .svn to store the Subversion data files and you should normally not modify or adjust any of the file files under this subdirectory. If you make subdirectories, each one will have its own .svn directory. You should only have to enter the location of your repository when you do the initial checkout. From then on, Subversion will know where to look for all its files based on the contents of the .svn metadata directories.

Getting Updates

Once you have started, the first thing you should do before beginning work each day is update your working copy. This will allow you to get any changes that others in your group have made since the last time you worked. It's very important to keep your working copy up-to-date because this reduces the number (and magnitude) of merge conflicts you will have. The following command (issued from inside your working directory) will update to the latest copy of all files:

svn update

If you have made local changes to a file, it will not be overwritten.

Making changes

There are four operations you will normally perform to make changes to files (assuming no conflicts):

svn add
svn delete
svn move
svn copy

You will use add to add new files and directories, and delete to remove existing ones. The move and copy commands are used more rarely. If you want to rename a file, you move it to its new name.

Committing Changes

Once you have finished making a set of changes, you can commit them back to the repository for the rest of your group to see:

svn commit --message "Short description of changes"

You might also choose to commit before you are finished if someone else in your group needs to make a small change in the middle of your large changes (or vise versa). The --message "" part of the command is useful because it provides you and your group with a history of the reasons for each change. For example, if someone says they will update a section, and you want to know if they did, you can look at the change log and (if they entered a message when they committed the changes) you will know if they did or not. To look at the project's change log, use:

svn log

If you omit the --message (or -m) options then Subversion will use the text editor defined by the environment variable EDITOR to open up a text editor that will allow you to edit the log message.

Checking Status

If you want to see what's going on while you are in the middle of changes you can use:

svn status
svn diff
svn revert

to look at the current project status, compare versions, or roll back to a previous version (respectively).

When Changes Collide

Unless you are the only one working in your Subversion repository it is likely that you will encounter a conflict. A conflict occurs when two people edit the same part of a file. The first person to commit their changes will have it easy. The other person will have to merge the changes in their local directory before they can commit. When you run the command svn update, files with a preceding C have conflicts that cannot be automatically handled by subversion. Files with a preceding G had local and remote changes, but they did not conflict and subversion handled the merge automatically. The best way to avoid conflicts is by communicating with your fellow developers and making sure that people aren't working on the same sections of code. Also try to avoid lengthy sets of changes to your working directory without committing your changes as this will reduce the chances of someone else making a conflicting commit before you.

When there is a merge conflict, Subversion will put conflict markers into the file to show you the problem areas. It will also place three files into your working directory:

filename.*.mine
filename.*.rOLDREV
filename.*.rNEWREV

The first, ending in .mine, is the file as it was before you tried to update. There will be no conflict markers here. The second, ending in .rOLDREV, is the file as it was before you started to make changes. The third, ending in .rNEWREV, is the file that is currently checked in with changes that conflict with yours.

To fix the conflict and check your changes in, you must edit the working copy (the file without any of the special extensions listed above), or replace it with one of the three files Subversion generated. Note that replacing your working copy with the filename.*.rOLDREV file will effectively remove your changes and the other person's changes. After fixing the working copy, remove all three of the Subversion generated files (filename.*.mine, filename.*.rOLDREV, and filename.*.rNEWREV). Once they are gone, you will be allowed to commit the changes.

When you edit the working copy of the file, you will find the conflict areas labeled with: <<<<<<< .mine where your changes are, ======= between your changes and the conflicting changes, and >>>>>>> .r2where the conflicting changes end. Make sure you find and fix all sections tagged like this.

After you've made the changes, run:

svn resolve filename

to tell subversion that the conflict has been resolved. This step should remove the Subversion created files for you. After that, you can try the commit operation again.

External Documentation

• Subversion Home Page 
• Subversion Book 
• Yo Linux Subversion Guide 
• Subversion Documents and Files