Overview over Subversion

Subversion is a version control system in which partners can cooperate on managing and tracking changes to programs and documents. The versioned document original is left on the (Subversion) server and the respective partners have local versions which they work on concurrently. Local version are synchronized with the repository by the subversion client by the actions

• checkout (a local version is created from the repository)
• update (changes from the repository are integrated into the local copy)
• commit (changes from the local version are integrated into the repository).

Obviously, a commit is only possible after a previous update, which synchronizes the local copy with the repository (otherwise version conflicts would occur).

Note that an update can cause conflicts in the local copy (in the repository a line that has been worked on in the local copy has also been changed in the repository) which have to be resolved by hand.

Here are the salient commands for a full documentation see http://svnbook.red-bean.com.

svn update (or svn up)

updates the local subdirectory (all the files there and recursively the subdirectories) to synchronize it with the repository. This does not overwrite the local changes, but merges them with the ones from the repository.

svn add filename or directory

schedules a file or directory for Subversion control.

svn remove filename or directory

deletes the file and tells Subversion that it should no longer control the file.

svn move filename or directory

moves a file or directory, this operation is under Subversion control transparently and is a definite improvement from CVS.

svn copy filename or directory

copies a directory. This is much better than the equivalent copy and svn add, since it allows version tracking across the copy.

All of the commands above only work on the local copy, therefore, in a final step, the result of these actions must be communicated to the subversion repository so that they can become permanent. We use

svn commit -m"log message"

integrates the local changes of all files (recursively) in the current directory into the repository. The log message will be saved with the changes and can be seen by other partners.

Of course you can only commit your changes, when your local copy is in sync with the repository (i.e. your changes are based on the current version of the repository). If it is not, you will have to run svn update again, which will merge changes committed to the repository by other people into your local copy, bringing it into sync again. Usually, changes are in different parts of the document, so that the merge is successful. Occasionally, merging is not possible, since you have made changes in the same line as the others, in this case, a conflict occurs, which has to be resolved by hand. This is tedious (but supported by tortoisesvn and emacs, and should be avoided by updating the local copy before any edits.

Generally, the procedure for working with CVS is always:

1. svn update
   1. resolve conflicts (relatively rare)
   2. your changes
   3. test whether everything runs/compiles/formats
2. svn commit -m"log message"

It is always a good idea to commit and update often, since this minimizes conflicts (tedious to resolve).