A brief howto about using Subversion/svn as client!

This is a very brief description how to use Subversion/svn as client!.

Subversion/svn - is a version management system, keeping track on changes of the files in its repository. For those familiar with CVS, starting with svn is quite easy.

some basic commands (called in a local working copy)

svn checkout https://svn-server/path/project . - creates a working copy of the project in your actual working folder
svn status informs you about differences between your local working copy and the content of the repository
svn update updates your local working copy. It will show information on updates like (taken from http://svnbook.red-bean.com):
U foo - File foo was Updated (received changes from the server).
A foo - File or directory foo was Added to your working copy.
D foo - File or directory foo was Deleted from your working copy.
R foo - File or directory foo was Replaced in your working copy; that is, foo was deleted, and a new item with the same name was added. While they may have the same name, the repository considers them to be distinct objects with distinct histories.
G foo - File foo received new changes from the repository, but your local copy of the file had your modifications. Either the changes did not intersect, or the changes were exactly the same as your local modifications, so Subversion has successfully merGed the repository's changes into the file without a problem.
C foo - File foo received Conflicting changes from the server. The changes from the server directly overlap your own changes to the file. No need to panic, though. This overlap needs to be resolved by a human (you); we discuss this situation later in this chapter.
svn commit puts local changes in the repository
svn add file/folder adds files and folders to the repository (svn commit has to be called afterwards)
svn delete file/folder removes files and folders from the repository (svn commit has to be called afterwards)
svn diff file shows differences of file in your local working copy with the latest revision in repository

some commands more seldom necessary

svn resolved --accept file on updates or commits, svn may complain about conflicts, that means files could not be merged automatically. You have to edit the file in your local working copy, and mark his as the version to be put in repository (svn commit has to be called afterwards)
svn propedit svn:externals project sets the externals property on project. Using externals you may "link" external files to the project. This is useful if you use files in project which belong to other projects. Instead of copying the file with all the problems keeping it up-to-date, you can add it as an external property:
With the above command, you will get an editor (maybe you want to set the EDITOR variable before, where you can refer to external files:
test.h https://svn-server/trunk/testproject/test.h
If somebody now checks out the project, the file test.h will also be checked out. The path to the file may be relative or absolut.
(svn commit has to be called after setting the property).
NOTE: svn also supports soft links, but this would mean, you have to checkout the file test.h separately and put it where the link points. No automatic checkout is done.
"Simple" tagging using svn copy http://svn-server/trunk/project http://svn-server/tags/release-1.0 -m "Tagging the 1.0 release of the project."
This is the same as creating a branch of project!
To tag not HEAD (the latest version) but a specific revision, execute svn copy -r 1234 ...
Complex tagging using svn copy my-working-copy http://svn-server/tags/release-1.0 -m "Tagging the 1.0 release of the project."
This would copy your entire working-copy as one tag, with all subfolders also tagged in the revision they are present in your working copy!
svn --username weindl (svn-commmand) ... overwrites the default user for that command, if working in an environment, where credentials of somebody else are already stored.
svn --no-auth-cache (svn-commmand) ... disables caching of the authorization for that command.

example how to tag aevread versions

In the svn-trunk, there is a project aevread_meta, which holds just a makefile, and has set all necessary files for the aevread library as svn:externals. This project is the basis to create new aevread versions. At the time, all files in the latest version are in a state to be combined to a version, do:

svn checkout https://devel-ik.fzk.de/svn/auger/AERA/trunk/aevread_meta aevread_meta. This will checkout the aevread_meta project with all files in the latest version.
svn copy aevread_meta https://devel-ik.fzk.de/svn/auger/AERA/tags/aevread/aevread_v01r00p00 copies the just checked out aevread_meta project will all files in the desired state as a version into the named folder.
The new versioned project still has the svn:externals set, which must now be removed: svn propedit svn:externals https://devel-ik.fzk.de/svn/auger/AERA/tags/aevread/aevread_v01r00p00
To put the new version on the wiki, get the new version: svn checkout https://devel-ik.fzk.de/svn/auger/AERA/tags/aevread/aevread_v01r00p00 aevread_v01r00p00. Remove the .svn folder from the folder and its subfolders lib src. Create a tgz: tgz aevread_v01r00p00.tgz aevread_v01r00p00 (or tar -czf aevread_v01r00p00.tgz aevread_v01r00p00) and put it on the wiki.

example how to add any folder (and subfolders) to repository

(I used this to create a tagged version of the AERA daqlight, which was edited outside the SVN tree.)
If you want to add any folder to the repository, it is best to make a copy of it, so no changes are made to the original folder.

copy the folder, easiest is to copy it to a working copy of the SVN tree, to the place, you want to have it later (e.g tags/daqlight_20110905)
make sure, no SVN information is in the copy of the folder and its subfolder. In the subfolder: find . -name .svn | xargs rm -rf
go to the parent folder and add the folder: svn add --force folder
commit the folder: svn commit folder -m "your commit message"

if your svn client version is to old ...

It may appear, that executing svn commands fail with a message like this:
svn: Der Client ist zu alt, um mit der Arbeitskopie ».« zusammen zu arbeiten.
This means, that your working copy has been switched to a newer and incompatible version of svn (maybe you temporarely used a newer version yourself, you copied the project or are working on the project from different systems (via nfs, VM,...)).
If newer versions are incompatible, this is usually related to new features, not supported by the old version.
That means, using a older version may result in loosing information!!
However, here is a script, that can be used to switch your project to older version.
change-svn-wc-format.py --help prints help information.
change-svn-wc-format.py project 1.5 switches project back to version 1.5.

Some links with further information:

http://svnbook.red-bean.com