From HaFrWiki
Jump to: navigation, search

Subversion is a version control system.
The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community.
The software is released under an Apache/BSD-style open source license.
The information of this site is a summary/collection of other sites, Tigris [1], Sliksvn [2] and Subclipse [3].

  • Most current CVS features.
    Subversion is meant to be a better CVS, so it has most of CVS's features. Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise.


Basic Subversion Commands[edit]

A complete manual can be downloaded at the Tigris site. This wiki contains a Cheat Sheet with the Basic Commands.

Update Changes Examine
Merge Commit Results
Detailed status info Conflicts Add
Diff Move for renaming copy for renaming


All version control systems has to solve the same fundamental problem:"how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository."

The problem to avoid!

Suppose two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost—or at least missing from the latest version of the file—and probably by accident. This is definitely a situation to avoid!

Many version control systems use a lock-modify-unlock model to address the problem of many authors clobbering each other's work. In this model, the repository allows only one person to change a file at a time. This exclusivity policy is managed using locks. Harry must lock a file before he can begin making changes to it. If Harry has locked a file, then Sally cannot also lock it, and therefore cannot make any changes to that file. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, Sally can take her turn by locking and editing the file.

Subversion, CVS, and other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client contacts the project repository and creates a personal working copy—a local reflection of the repository's files and directories. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.

But what if Sally's changes do overlap with Harry's changes? What then? This situation is called a conflict, and it's usually not much of a problem. When Harry asks his client to merge the latest repository changes into his working copy, his copy of file A is somehow flagged as being in a state of conflict: he'll be able to see both sets of conflicting changes, and manually choose between them. Note that software can't automatically resolve conflicts; only humans are capable of understanding and making the necessary intelligent choices. Once Harry has manually resolved the overlapping changes—perhaps after a discussion with Sally—he can safely save the merged file back to the repository.

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 far less than the time lost by a locking system.

Sometimes locking is needed. When a file consists of binary data, it's often difficult or impossible to merge two sets of changes made in parallel by different users. For this reason, Subversion offers a feature known as locking, often known as reserved checkouts in other version control systems.


There are three different kind of lockings. Only the first is meant to be used by the client, the others are reserved to the VC.

  1. Client locks, mechanism for mutual exclusion between users to avoid clashing commits.
  2. Working copy locks, used internally by Subversion to prevent clashes between multiple Subversion clients operating on the same working copy.
  3. Database locks, used internally by the Berkeley DB backend to prevent clashes between multiple programs trying to access the database.

When a commit fails due to someone else's locks, use:

 svn status -u

Powerdesk problems[edit]

Whenever right click on a folder in PowerDesk or in Windows Explorer, the application crashes. This problem occurs using PowerDesk 5 in combination with Subversion Tortoise. Powerdesk version 6 does not have any problems.

This is a bug in PowerDesk. There is a fix for Powerdesk 5, but it's not available on their website; you have to contact support to get it. They'll give you an update to a later version ( - which is strangely not on the update portion of the site) then send you a patch to bring you to which fixes the problem.


Disable ownerdrawn menus in TortoiseSVN using regedit:

  • Go to the registry key HKEY_CURRENT_USER\Software\TortoiseSVN
  • Create a DWORD value named OwnerDrawnMenus
  • Set its value to 2


Use version 6.0 of Powerdesk. See

Non Canonical Path[edit]

A common problem with Subversion is the error: svn: Entry contains non-canonical path. This error occurs in my case when the Initial Check-Out has been done using Syncro SVN. The program creates an entries file in the .svn directory with lowercase drive letters. My SlikSvn command line subversion client does not like this and produces the above message.


  1. Do the checkout again, but use the command line SlikSvn. This is the most simple way.
  2. Edit all entries and change the drive-letters into Capital DriveLetters. Use a global find-replace tool.

Move your repository[edit]

Migration of the repository to another location is not so easy to do. If the name and/or stucture is not changed it can be done using:

 svn switch

A detailed description will be given later. In practice this will not work (at least it did not for me).

A possible second result of the migration is the occurrence of the errormessage:

Caused by: org.tigris.subversion.javahl.ClientException: Working copy text base is corrupt
svn: Checksum mismatch while updating 'xxxx'; expected: '0f9246264b8b41ad2df10ec39a4fbc72', actual: '87ac25aa5e7194b5c9c9fd22717fdbad'


First of all make a copy of your checked out repo. Use a good search and replace tool (Funduc Search and Replace [4] [5] ). Search for the name of the old repository name in all entries files (located in the .svn directories of the checked out repo). Replace the name with the new names.

The second problem can be solved by making a change to the entries files. Check your repo out in a temp-dir. Open the entries file in the .svn directory and look for the checksum of the troubled file. This looks like:


Take this checksum out of this entry file and place it in the old checkout. Also copy the file from the text-base directory into your original check out repo. Try to update the repo now. It should work fine.




  • Abbey Workshop, Subversion Cheat Sheet
  • Cheat Sheet, Quick Reference for Command-line and Eclipse plugin (recommended).
  • IBM Subclipse, Subversion and Eclipse overview/information.
  • Oxfort University Computin Services, using the Syncro Subversion Client
  • QSVN, GUI for windows but not great in showing the results.
  • Subclipse, Subversion plugin for eclipse documentation.
  • Subversion Tigris official website.
  • TortoiseSVN website.
    • TortoiseSVN Subversion and Powerdesk problem (Powerdesk 5). The new powerdesk versions don't have these problems. The combination Tortoise and Vista causes major problems.


For an overview of the subversion clients look at Subversion Tigris Clients Link.


CollabWeb is the currently most used server.

Users in CollabNet[edit]

To make it possible to see the check-in of users add the following to the file svn-authz.conf in the CollabNet server (On Windows c:\Program files\Collabnet).

team = riet
devteam = hjmf,ibm,apple,mpro

@team = r
@devteam = rw

@team = r
@devteam = rw

@team = r
@devteam = rw

@team = r
@devteam = rw

En daarna

htpasswd.exe -b <name-of-pass-file <uid> <pwd>

DNS Problem[edit]

One of the problems with Windows Workgroups and Mac OS X installations is that they can not find each other by name, but can when using the URL-IP-Addresses. In that case create an entry in the Host on iMac. This file is located in /etc, and is called hosts. Please be very careful when changing this file. Add an entry like name

to the existing entries. So the file will look like

 # Host Database 
 # localhost is used to configure the loopback interface
 # when the system is booting.  Do not change this entry.
 ## Added by Harm for subversion, see wiki website for more information. harm
 # End addition by Harm for subversion   localhost broadcasthost
 ::1             localhost
 fe80::1%lo0 localhost

This is very short description and will be later edited!!!

See also[edit]


  • CVS, Savannah Concurrent Version Systems by Savannah.
  • Git, Another VCS system.
  • PVCS, Polytron Version Constrol System from Serena (earlier Merant).
  • Wikipedia, List of revision control software



  1. Tigris Subversion Website
  2. SlikSVN, A SVN implementator
  3. Subclipse, Tirgis Eclipse plugin
  4. Funduc Software Inc, Search and replace.
  5. Funduc Search and Replace, Funduc SR tips and tricks on Wiki Harm