I came across a Subversion wiki and a Subversion forum which seem to contain good information about setting up and using Subversion.

Here are a few more Subversion tips from Rafael Garcia-Suarez’s article at ONLamp.com

Tags and Branches

A simpler way of retrieving any previous state of a file within your working copy is to use svn update. This command updates its targets to their state at a specified revision (defaulting to the HEAD revision). For example,

$ svn update -r42 include

reverts the include directory (and its contents) to the 42nd revision. (update is also used when you want to integrate changes from another working copy into your working copy, but we’ll cover this in another article.) Subversion provides a more powerful mechanism to track the release points of your projects: tags and branches. There is no difference, from Subversion’s viewpoint, between tags and branches; the difference is in how you use them.

To create a tag or a branch, use the svn copy command. svn copy makes a copy of a versioned resource (a file or a directory), while retaining history. In other words, it doesn’t add a file (or a whole tree) — it only marks a new entry in the repository as being indentical to another one, at a specified revision. Thus, copies occur done in constant time, although they may logically create huge parallel trees.

Let’s take an example. Suppose I’ve just released a new frobnizer, version 2.0, and I want Subversion to remember for me that frobnizer v2 corresponds to revision 42. Assuming the current revision level of directory trunk in my working copy is 42, I’ll say:

$ cd ~/frobwork
$ svn copy trunk frobnizer-2.0
$ svn commit -m ‘Release v2.0′

My repository has now two main subdirectories: /frobnizer/trunk and /frobnizer/frobnizer-2.0. They branch from the same revision, but can now evolve separately.

If I decide to not commit any changes to the /frobnizer/frobnizer-2.0 subdirectory, it’s called a tag. Otherwise, it’s a branch. The advantage of a tag is obvious. It’s possible to check out /frobnizer/frobnizer-2.0 to get the source for the frobnizer v2.

Branches are mainly useful when a team of developers have commit access to a same repository. If a long, experimental development has to be made, it’s better to create a branch, make the changes in it, and reintegrate them into the trunk when the development is finished. This avoids interferences. Subversion provides a mechanism (the svn merge command) to report the changes made in one branch into another. Branches may not be very useful to you if you’re the only Subversion user on your system, and that’s why I won’t elaborate on this subject. However, the Subversion developers recommend to create two subdirectories, branches/ and tags/, along the trunk/, to store branches and tags. (This is how the Subversion repository is organized.)
Distribution

Now that you’ve fixed many bugs, you’ve decided to release another version of your project as a source tarball.

You can’t just tar+gzip your working copy: it contains hidden Subversion files and probably also some other temporary files (backups, object files, etc.). The svn export command is here to help you. It checks out a specified version without including metadata.

$ svn export file:///home/rafael/svn/frobnizer/frobnizer-2.0
$ tar cf frobnizer-2.0.tar frobnizer-2.0
$ gzip -9 frobnizer-2.0.tar

Don’t Forget …

… to make backups! Your repository holds important information. It’s possible to dump the contents of the repository (including all revisions) into a dumpfile. This format is portable, and you can use it to reconstruct a repository if necessary.

For example, it’s useful to have, in a crontab, something like :

svnadmin dump /home/rafael/svn | gzip -9 > dump.gz

This way, the repository can be restored via

gunzip -c dump.gz | svnadmin load /home/rafael/svn

Finally, many people need to configure multiple Subversion repositories because they are working on more than one project. To learn how to authenticate Subversion users via a database check out this article from debian-administration.org. It is Debian specific, but could be adapted to other distributions.