SVN notes

Official Website

Official Documentation


= = This document is written for people who intend to build Subversion from source code. Normally, the only people who do this are Subversion developers and package maintainers.

find binary packages:

For OS X:

For windows:

Copy-modify-merge model

The copy-modify-merge model may sound a bit chaotic, but in practice, it runs extremely smoothly. Users can work in parallel, never waiting for one another. When they work on the same files, it turns out that most of their concurrent changes don’t overlap at all; conflicts are infrequent. And the amount of time it takes to resolve conflicts is usually far less than the time lost by a locking system.

When Locking Is Necessary

The copy-modify-merge model is based on the assumption that files are contextually mergeable—that is, that the majority of the files in the repository are line-based text files (such as program source code). But for files with binary formats, such as artwork or sound, it’s often impossible to merge conflicting changes. In these situations, it really is necessary for users to take strict turns when changing the file.

Working Copy & Repository

In Subversion, the client-side object which every user of the system has—the directory of versioned files, along with metadata that enables the system to track them and communicate with the server—is called a working copy. Although other version control systems use the term“repository” for the client-side object, it is both incorrect and a common source of confusion to use the term in that way in the context of Subversion.
A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files.

Atomic transaction

A Subversion client commits (that is, communicates the changes made to) any number of files and directories as a single atomic transaction. By atomic transaction, we mean simply this: either all of the changes are accepted into the repository, or none of them is. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users’ actions.


Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number assigned to the previous revision. Unlike most version control systems, Subversion’s revision numbers apply to the entire repository tree, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Notice that in general, revisions N and M of a file do not necessarily differ!

How the working copy works

four states of a working file:
  • Unchanged, and current
  • Locally changed, and current
  • Unchanged, and out of date
  • Locally changed, and out of date. – where conflict happens

Mixed revisions

The things you just committed are marked as having larger working revisions than everything else. After several commits (with no updates in between), your working copy will contain a whole mixture of revisions, even if you’re the only person using the repository.
You cannot commit the deletion of a file or directory that isn’t fully up to date.

$svn import

Note that after the import is finished, the original local directory is not converted into a working copy. To begin working on that data in a versioned fashion, you still need to create a fresh working copy of that tree.

$svn checkout

Most of the time, you will start using a Subversion repository by performing a checkout of your project.

$svn update

it’s best to have the latest versions of all your project’s files and directories before making new changes of your own.

In addition to all of the previous commands, you can use the –revision (-r) option with svn update to take an entire working copy “back in time”.

If you decide that you don’t need to merge any changes, but just want to accept one version of the file or the other, you can either choose your changes (a.k.a. “mine”) by using the “mine-full” command (mf) or choose theirs by using the “theirs-full” command (tf).

$svn status

If you run svn status at the top of your working copy with no additional arguments, it will detect and report all file and tree changes you’ve made.

  • ? item
    The file, directory, or symbolic link item is not under version control.
  • A item
    The file, directory, or symbolic link item has been scheduled for addition into the repository.
  • C item
    The file item is in a state of conflict. That is, changes received from the server during an update overlap with local changes that you have in your working copy (and weren’t resolved during the update). You must resolve this conflict before committing your changes to the repository.
  • D item
    The file, directory, or symbolic link item has been scheduled for deletion from the repository.
  • M item
    The contents of the file item have been modified.

$svn checkout

Most of the time, you will start using a Subversion repository by performing a checkout of your project.

$svn log

To find information about the history of a file or directory, use the svn log command.

$svn list

The svn list command shows you what files are in a repository directory without actually downloading the files to your local machine.

Recommended Repository Layout

  • Most projects have a recognizable “main line”, or trunk, of development; //check out the trunk
  • some branches, which are divergent copies of development lines;
  • some tags, which are named, stable snapshots of a particular line of development.

Directory Changes

But sometimes you need to add, remove, copy and move files and directories—the svn add, svn delete, svn copy, andsvn move commands handle those sorts of structural changes within the working copy.
These changes may take place immediately in your working copy, but no additions or removals will happen in the repository until you commit them.


Customizes things without effecting the main line, since they do things slightly differently.
Let’s say that you’ve been given the task of implementing a large software feature. It will take a long time to write, and will affect all the files in the project. The immediate problem is that you don’t want to interfere with Sally, who is in the process of fixing small bugs here and there. She’s depending on the fact that the latest version of the project (in /calc/trunk) is always usable. If you start committing your changes bit by bit, you’ll surely break things for Sally (and other team members as well).

The better solution is to create your own branch, or line of development, in the repository. This allows you to save your not-yet-completed work frequently without interfering with others’ changes and while still selectively sharing information with your collaborators.

Copying a directory on the server, however, is a constant-time operation, and it’s the way most people create branches.

$ svn copy ^/calc/trunk ^/calc/branches/my-calc-branch \
-m “Creating a private branch of /calc/trunk.”

Subversion’s repository has a special design. When you copy a directory, you don’t need to worry about the repository growing huge—Subversion doesn’t actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. In fact, this feature is the basis of how commits work in Subversion: each revision is a “cheap copy” of the previous revision, with a few items lazily changed within. Make branches as often as you want. It’s cheap – both time and space.

Now that you’ve created a branch of the project, you can check out a new working copy to start using it.

And when you’re completely finished with your branch, your entire set of branch changes can be copied back into the trunk.