From charlesreid1

For a more advanced guide to using Subversion, see Subversion Beyond the Basics page




I had to install Apache for the APR and APXS bindings.

See Apache


I had to install Neon to use the http/https protocol in SVN. Neon is an HTTP and WebDAV client software. I installed it to /usr and installed with SSL.

See Neon


SWIG provides language bindigns (see

Mac OS X (Snow Leopard) and Ubuntu already come with SWIG.

If you are interested in installing SWIG and do not have it already, you can find instructions in your subversion source directory, in:


This describes the steps for installing SWIG and language bindings.


I also had to install sqlite, which involved basically downloading the "amalgamation" from SQLite's website, then moving sqlite3.c into the subversion source as specified by svn's configure. I'm not sure what the .c file does, but it basically takes care of the sqlite dependency.

Configuration (1.5)

I configured subversion version 1.5.2 with the following configure line:

# run this configure script
# make
# make install

./configure \
 --prefix=/path/to/subversion \
 --with-ssl \
 --without-berkeley-db \
 --enable-swig-bindings=yes \
 --with-apxs=/path/to/apache/bin/apxs \
 --with-neon=/usr/local \
 --with-apr=/path/to/apache \

I have to point subversion to apache so that it can handle subversion repository addresses that begin with http:// or https:// (as opposed to the default svn://, which works fine out of the box).

I then ran

make -j2 all
make install

Configuration (1.7)

I was able to configure subversion 1.7 with the following configure line:

./configure \
    --prefix=$HOME/pkg/svn/1.7.1 \
    --with-ssl \
    --without-berkeley-db \
    --with-swig \
    --with-apxs=$HOME/pkg/apache/std/bin/apxs \
    --with-neon \
    --with-apr=${HOME}/pkg/apache/std \
    --with-apr-util=${HOME}/pkg/apache/std \
    CC="/usr/bin/gcc" \
    CXX="/usr/bin/g++" \

If you run into problems with OpenSSL or other SSL-related things, try changing the first line of this to:

LIBS="-lcrypto -lssl" ./configure \

Making SWIG Bindings

To make the swig bindings, you'll have to configure with the --with-swig flag.

You must run make/make install for swig bindings separately from make/make install for the rest of the svn program.

From the source directory, after running make/make install, run:

$ make swig-py
$ make install-swig-py

SVN Guide

Check the Status

To check the status of a local copy of an SVN repository, run:

$ svn status /path/to/repository

or run the svn status command from the repository itself, at /path/to/repository.

Tis will give the status of any files that have been added, removed, modified, etc. The codes include:

A = this file will be added to the repository on the next check-in
D = this file will be deleted from the repository on the next check-in
M = this file has been modified from the repository version
? = local file that is not part of repository
! = repository file that does not exist locally
C = this file is in a conflict that needs to be resolved


In order to make the working copy up-to-date with the remote repository, use the svn update command:

$ svn update /path/to/repository

or run the svn update command from the repository location. Some important things to know about the update command:

  • if a file has been modified:
    • SVN update will not touch any modified lines
    • SVN update will try to update the untouched portions of the file
    • SVN update will create a conflict if you have modified lines that have been updated

There are a couple of codes that SVN update will show for each file it touches. These include:

A = added file
D = deleted file
U = updated file
C = conflict
G = merged file

The last one, "merged file", means there were modifications in the file, but SVN was able to successfully update the untouched portions of the file.

Making changes to a working copy

Adding file/directory:

$ svn add foo

If foo is a directory, it will be added recursively.

To only add the directory foo/ itself, and not its contents, use the --non-recursive (-N) argument.

To delete a file or directory:

$ svn delete foo

If foo is a directory, it is not immediately deleted, but is SCHEDULED for deletion.

When you commit your changes, it will be deleted.

Copy a new item (new_item) from an old item (old_item):

$ svn copy old_item new_item

To move a file from <code:location1/</code> to location2/:

$ svn move location1/ location2/

This is the same as running svn copy location1/ location2/; svn delete location1/

To make a new directory:

$ svn mkdir foobar

This is the same as running mkdir foobar; svn add foobar

foobar/ is a new directory that is created and scheduled for addition

Submitting changes

First, you can check what files you have changed:

$ svn status

Next, you can check exactly what changes you have made:

$ svn diff

or you can diff a particular file:

$ svn diff file

(or, to pipe into an external file and review changes there:)

$ svn diff > diff_file

If you are happy with your changes, then commit your changes:

$ svn commit -m "your log message here"

Alternatively, if your $EDITOR environmental variable is set, you can run

$ svn commit 

and the editor will open, and you can enter your log message there (good for complex log messages).

If you want to commit a particular file, just specify that file when you run the commit command:

$ svn commit file1 file2 file3 -m "your log message here"

Looking at differences

The command to see the differences between your working copy and the repository copy is

$ svn diff

To look at differences between different revisions:

Example: Compare revision 3000 to revision 3500 using “@” syntax:

$ svn diff
--- COMMITTERS  (revision 3000)
+++ COMMITTERS  (revision 3500)

Example: Compare revision 3000 to revision 3500 using range notation (you only pass the one URL in this case):

$ svn diff -r 3000:3500
--- COMMITTERS  (revision 3000)
+++ COMMITTERS  (revision 3500)

Example: Compare revision 3000 to revision 3500 of all files in trunk using range notation:

$ svn diff -r 3000:3500

Working copy information

You can determine the version number of your working copy by running:

$ svnversion


$ svnversion . svn://hostname/project

Trailing letters mean:

M - modified working copy (there have been modifications made from the latest revision of svn://hostname/project)

S - switched working copy (meaning the repository server has been switched)

You can get more information about your local working copy by running:

$ svn info TARGET

(TARGET = working copy or URL)

To get info about a specific revision:

$ svn info TARGET -r

The info command will give you revision number, revision author, revision date and time, and svn server location.

Looking at the log


$ svn help log

To look at log message related to changes in the current directory (.), use:

$ svn log

To look at the log messages for changes to a particular folder or file:

$ svn log

To look at the log for a particular revision of a file, use -r:

$ svn log -r 5

To look at the latest revision, use:

$ svn log -rHEAD

Or, look at a series of revisions:

$ svn log -r <min>:<max>

To print all directories affected by the revision displayed, use -v

$ svn log foobar -v

(this may be a lot of output, since it's going all the way back to the initial check-in)

To supress the log messages, and just show info on when an update occurred, use the -q flag:

$ svn log foobar -q

combine to get what you want... e.g. to see the files that were affected by a particular revision:

svn log -r 2 -v

Changing commit properties

You can change properties of svn files and commits by using

$ svn propset

Here are some examples:

Set the mime type on a file:

$ svn propset svn:mime-type image/jpeg foo.jpg
property 'svn:mime-type' set on 'foo.jpg'

On a UNIX system, if you want a file to have the executable permission set:

$ svn propset svn:executable ON somescript
property 'svn:executable' set on 'somescript'

Perhaps you have an internal policy to set certain properties like "owner" for the benefit of repository users:

$ svn propset owner charles
property 'owner' set on 'foo.c'

If you made a mistake in a log message for a particular revision and want to change it, use the --revprop flag and set svn:log to the new log message:

$ svn propset --revprop -r 25 svn:log "This is the new log message."
property 'svn:log' set on repository revision '25'

Or, if you don't have a working copy, you can provide a URL:

$ svn propset --revprop -r 26 svn:log "This is the new log message." svn://hostname/repository 
property 'svn:log' set on repository revision '26'

Lastly, you can tell propset to take its input from a file. You could even use this to set the contents of a property to something binary:

$ svn propset owner-pic -F charles.jpg
property 'owner-pic' set on ''

SVN Server

Some syntax:

Subversion is run as a server or as a client. Users (clients) check out files from a server.

A subversion server can have many different repositories, or it can have just one.

The following guide covers how to set up a subversion server, and how to create new repositories in the server.

Setting up a new SVN server

Any computer can be run as an SVN server. You can run the SVN server locally, on a local network, or on the internet.

To run a computer as an SVN server, you need to first install SVN, then open port 3690 on the machine that will be the SVN server, in case there is any firewall on that machine. Port 3690 is the port that is used by the SVN server and clients to communicate.

Once you do these things, you can create a repository using the svnadmin command, as described in the next subsection.

The visibility of the SVN server depends on the visibility of your machine (specifically, port 3690). Details are described below.

Setting up a local SVN server

If port 3690 is closed, then your SVN server will only work locally - that is, on your machine and your machine only. You can access your SVN server using the local machine's IP address,, or its address, localhost, by prefixing it with svn://:

$ svn info svn://

$ svn info svn://localhost/repository

If you have SVN set up to work with Apache, then your repository should also be accessible using either the http:// or https:// prefix:

$ svn info http://localhost/repository

$ svn info https://localhost/repository

But remember that if you are doing this, and you are building SVN from source, you have to link to a version of Apache and a version of Neon - otherwise http:// and https:// won't work.

Setting up a LAN SVN server

LAN = local area network

If the SVN server computer has port 3690 open, then other computers can communicate with the SVN server. If the computer is on some local network of computers (say, a home wireless network or an office wired network), and port 3690 is visible to other computers, then other computers on the local network can access the SVN server. These types of networks have a router or gateway to the wider internet, so that traffic coming in from the wider internet is controlled. This means that the SVN server would only be accessible to the outside world if it was explicitly made visible (e.g. by forwarding a port associated with the router's IP address to the port of the SVN server computer).

Setting up a "public" internet SVN server

Keep in mind through all of these discussions that SVN still provides authorization and password control, so a "public" SVN server does not mean the repository is accessible by the public, it simply means it is visible by the public.

This can be done from behind a network as described in the previous section, by rerouting traffic to a certain port on the router to a certain port on the computer that is the SVN server (typically 3690 to 3690, but it may be of interest to use a non-default port). If the computer has a public IP address, making an SVN server accessible to the public is a simple as installing SVN and opening port 3690.

Creating a new repository

Step 1: crate a place for the subversion repository

$ svnadmin create /path/to/repositories/repository_name

Step 2: import files into the repository:

$ svn import /location/of/files file:///path/to/repositories/repository_name -m "Initial import"

(You must use file:///path/ syntax, rather than an absolute path).

Step 3: check out code from the new repository

$ svn checkout svn://hostname/repository_name working_copy --username=user

Protecting a repository

By default, anonymous users may access repositories, but they have read-only access. In order to change permissions and visibility levels, edit the repository's conf/svnserve.conf and conf/passwd files. These can be used to disable anonymous access, create usernames and passwords, and specify default permissions levels as well as edit permission levels for individual users.

Using SVN Server Securely

To use an SVN server securely, you can use SVN over SSH by giving the address of the SVN repository like this:

$ svn info svn+ssh://address/repository

Configuring SVN over HTTP/HTTPS

Some repositories have an address using http://address or https://address instead of svn://address. This is because the SVN server has been configured to be used over HTTP or HTTPS.

Once you have a repository created and set up, and you can access it using a svn or svn+ssh prefix, you can convert it to using a http or https prefix by doing the following:

Step 1. Modify httpd.conf

The Apache httpd.conf file should include the DAV and AUTHZ modules:

LoadModule dav_svn_module     libexec/apache2/
LoadModule authz_svn_module   libexec/apache2/

And the location of the repository set up to be accessed via SSH:

<Location /repo>
   DAV svn
   SVNPath /usr/local/repo

One website [1] advises putting these new directives into a file called httpd-subversion.conf and then including that in the main httpd.conf file by adding this line:

Include /path/to/apache/conf/httpd-subversion.conf

To use HTTPS, you have to set up an SSL certificate for your server; to figure out how to do that, try these resources: