SVN Basics

This page includes explanations of terms and commands for Subversion / SVN.

Terminology

remote repository - the remote copy of the code etc. maintained by the Subversion server

repository root - the base URL of the repository such as svn://svn.freehep.org/hps/

structure node - any part of the repository under the root, which can be conceptualized as a directory on a file system, with the repository root as the "/" or root directory.

working copy - your copy of an SVN module including local changes

revision - a globally unique number to the repository tagging the state of the repository after a commit (including add, delete, etc.)

commit - push your changes to the repository, making a new global revision

revision - a global revision number tagging the state of the repository after a commit.

trunk - the remote repository's current revision, similar to "HEAD" in CVS terminology

tag - a copy of the trunk from some certain point in time, which should not be modified once created; usually kept in a node called 'tags'

branch - a fork of the trunk (or some other version of the code) which is for development and can be modified after it is created; usually kept in a node called 'branches'

merge - combining together two copies of (usually) the same node in order to merge their changes

Commands

All commands below assume that you are in a command shell like bash on Linux and that the current working directory is a local working copy of a structure node that has been checkout out of the repository.

Checkout a structure node

svn co svn://repo/some/dir

Show information about the repository

This command will print out general repository information like your current revision # and the repository root.

svn info

Check the status of your local working copy

This command will list all your changes and additions in the local working copy:

svn status

Each file will have a letter next to it, such as:

M = locally modified

? = not tracked by Subversion

A = added

D = deleted

etc.

Check the SVN docs for a full list of all these commands.

Show node contents

svn ls some/relative/path/

or

svn ls svn://repo/some/path/

Synchronize your copy with the remote repository

svn up

Add files to the repository

This command can be used to add files:

svn add rel/path/to/file1 rel/path/to/file2

These will then be pushed to the remote repository when you execute a commit.

Delete files from the repository

This command can be used to delete files:

svn rm rel/path/to/file1 rel/path/to/file2

The deletion will occur when you commit.

Commit changes

This command is used to commit your local changes to the repository:

svn commit -m "committing some stuff" [optional/path/to/file1] [optional/path/to/file2]

The list of files or directories to commit is optional, but it is usually a good idea to include it.

Copy file or directory from one place to another

svn cp src/dir/or/file target/dir/or/file

Create a directory in the repository

svn mkdir path/to/dir

Tips and Warnings

Be careful when using 'svn add' and 'svn commit' without any arguments, either from the command line or from the top-level in your IDE e.g. the infamous Team > Commit from an Eclipse project.  This may cause many files to be added to the repository that should not be tracked and will need to be removed.  Once a file is added, it is tracked 'forever' by the repository and not deleted, even though it might be removed in the trunk.

When executing more complex commands such as 'svn merge' use the '--dry-run' argument like 'svn --dry-run merge' to see what will happen without the command actually being executed.

Do not be too dependent on the IDE for using Subversion.  Make sure to have a compatible SVN command line client available e.g. where the SVN minor version number is the same as your IDE's "connector" version (Eclipse), so that you are able to execute shell commands.

At the beginning of the work day, do an 'svn up' in order to synchronize your working copy with the repository.  This will make sure you do not cause conflicts by modifying a file that someone has already made changes to in the repository.

Do not develop code in your working copy for an extended period of time without committing it, provided that checking it in does not cause a compilation or test case failure.  This is especially true if there is the possibility that someone else is working on the same file.