Subversion day to day

If you are using a graphical user interface to Subversion (such as Tortoise SVN), all the commands described here should be available from the menus.

Subversion's Working Cycle

The normal working cycle in terms used by Subversion is:

# checkout/update
# test
# edit (add/delete/copy/move)
# test
# commit

Getting Started

We can illustrate this working cycle using our example project. The sections below gives examples of common commands when using the command line client.

Checkout

The first step is to checkout a copy of the files:

svn checkout http://source.ggy.bris.ac.uk/subversion/myproject/trunk --user-name mylogin workingcopy

Where you can optionlly provide a user-name and the name of the directory/folder in which to create your local copy--in this case workingcopy.

Note that we specify trunk in the repository URL. The trunk distuinguishes these files from those which may exist on a branch of the repository. Branching is more advanced than we need concern ourselves with at the moment. For now, just note that we will be using the trunk at all times.

Update

To update your working copy, first move to the directory holding your local copy and then use update:

cd workingcopy
svn update

This will bring you local copy in line with the latest version stored in the repository.

Test

The tests that you make will be particular to your project. Experience has shown that having your test suite fully automated and incorporated directly into you build system (e.g. your set of makefiles) pays dividends. The time spent setting this up is repaid many times over in the time saved when a bug inevitably finds its way into the code. Please contact an administrator if you would like to discuss setting up your test suite.

Edit

You can, of course, edit the files in your local copy in whichever way you like. You might also like to add a new file, delete one completely, rename or copy an existing one. Subversion supports all of this.

svn add foo

This schedules foo to be added to the repository. Next time you commit your changes, foo will appear in the repository. If foo is a directory, foo and everything underneath will be added. svn delete foo works in a similar way to add.

To copy an item:

svn copy foo bar

Or to move an item:

svn move foo bar

This is equivelant to svn copy foo bar; svn delete foo.

Subversion provides some handy tools for reviewing what changes have been made. For example:

svn status

will look through all files in the where it was called and produce a short report on which files have been modified, which are scheduled to be added or deleted etc.

To find out exactly you've changed things relative to the repository, use:

svn diff

If you find that you've changed a file in error:

svn revert myfile

will recover a pristine copy of myfile exactly how it was before your changes.

Test Again

You will definitely want to make sure that the changes you made are working as you had hoped. Just before you commit your changes is the time to be certain that everything is tickety-boo. By doing this, you are likely to save yourself a whole load of time and heart-ache later on.

Commit

Now that you have made and tested your changes, it is time to create a new version of the repository. An invaluable feature Subversion provides is the ability to record a log message at this time. Later you, and your project partners, will be able to look back and say, "Oh THAT's why we made those changes", rather than a lot of head scratching and quizical looks culminating in a resigned "I think we'd better start again.."

svn commit --message "Fixed rounding bug in myfile"

More Information

You can find out more about using Subversion and about it's more advanced features (such as merging changes, branching etc.) in the Subversion book.