Product SiteDocumentation Site

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
2. Make your changes
3. Review your changes
4. Fix your mistakes
5. Resolve any conflicts (merge others' changes)
6. Publish (commit) your changes

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?