4.5. The Basic Subversion Work Cycle

(Adapted from Version Control with Subversion under Creative Commons Attribution License v2.0.)

Subversion has numerous features, options, bells, and whistles, but on a day-to-day basis, odds are that you will use only a few of them. In this section, we'll run through the most common things that you might find yourself doing with Subversion in the course of a day's work.

The typical work cycle looks like this:

1. Update your working copy

This involves the use of the svn update command.

2. Make your changes

The most common changes that you'll make are edits to the contents of your existing files. But sometimes you need to add, remove, copy and move files and directories. The svn add, svn delete, svn copy, and svn move commands handle those sorts of structural changes within the working copy.

3. Review your changes

The svn status and svn diff commands are critical to reviewing the changes you've made in your working copy.

4. Fix your mistakes

Nobody's perfect, so as you review your changes you may spot something that's not quite right. Sometimes the easiest way to fix a mistake is start all over again from scratch. The svn revert command restores a file or directory to its unmodified state.

5. Resolve any conflicts (merge others' changes)

In the time it takes you to make and review your changes, others might have made and published changes, too. You'll want to integrate their changes into your working copy to avoid the potential out-of-dateness scenarios when you attempt to publish your own. Again, the svn update command is the way to do this. If this results in local conflicts, you'll need to resolve those using the svn resolve command.

6. Publish (commit) your changes

The svn commit command transmits your changes to the repository where, if they are accepted, they create the newest versions of all the things you modified. Now others can see your work, too!

4.5.1. Update Your Working Copy

When working on a project that is being modified via multiple working copies, you'll want to update your working copy to receive any changes committed from other working copies since your last update. These might be changes that other members of your project team have made, or they might simply be changes you've made yourself from a different computer. To protect your data, Subversion won't allow you commit new changes to out-of-date files and directories, so it's best to have the latest versions of all your project's files and directories before making new changes of your own.

Use svn update to bring your working copy into sync with the latest revision in the repository:

$ svn update
Updating '.':
U    foo.c
U    bar.c
Updated to revision 2.
$

In this case, it appears that someone checked in modifications to both foo.c and bar.c since the last time you updated, and Subversion has updated your working copy to include those changes.

When the server sends changes to your working copy via svn update, a letter code is displayed next to each item to let you know what actions Subversion performed to bring your working copy up to date. We cover the meaning of these letters shortly.

4.5.1.1. Exercise - Get Updates From the Sample Repository

Update your working copy of the CS390X repo. Has anything changed?