To edit or add content to this Wiki, you can simply create a new account at

Skip to end of metadata
Go to start of metadata


Subversion is a commonly used Source Code Management ("SCM") tool. You should be using a SCM tool even if you are developing on your own! A Subversion setup consists of a number of "parts"

  • A source code repository.
    • If you are part of a team, this may just be provided to you as a URL that you use to access the repository. Otherwise you can easily create your own repository.
  • The Subversion binaries
    • The Subversion binaries need to be installed on your system - normally Subversion (aka "svn") is pre-installed on OS X, or at least it is installed when you install the developer tools. There are also excellent 3rd party binary installations available with Subversion extras included.
  • Eclipse Plugin.
    • Subversion on its own is a command line tool. There are many GUI clients available. For WebObjects development, it makes most sense to use an Eclipse plugin. You can use Subversive plugin or the Subclipse plugin.



Notes about using subversion with WebObjects, Interface Builder, and Mac OS X.

Slightly out of date information below

The information below is slightly out of date since WebObjects development is now standardized to Eclipse tools


Versions Used:

  • Mac OS X 10.4.2
  • subversion 1.2.3
  • Interface Builder 2.5.1 (439)
  • XCode 2.1
  • WebObjects 5.3

Appendices C and D of the Apple XCode User Guide (Using Subversion and Configuring Your SSH Environment) were fairly helpful in getting things set up although I would recommend installing subversion via the download links on the main subversion web page rather than using DarwinPorts. The binary version available via these links is easier to install since it uses a traditional double clickable package installer. Note that your install path will be /usr/local/bin instead of /opt/local/bin.

I also found the book "Version Control with Subversion" by Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato to be very helpful.

  • When creating the repository it seems preferable to use the file system rather than the Berkeley DB. To do this, pass the --fs-type fsfs flag to the create command.
    For example: svnadmin create --fs-type fsfs /path/to/repos
  • There are at least three different ways to authenticate to the repository. I used the svn+ssh method although I'm sure the others would work as well.
  • If you use the ssh+svn method, it's helpful to provide a virtual repository path so that end users don't have to type the entire path. For example, in my authorized_keys file, my key begins with:
    command="/usr/local/bin/svnserve -t -r /Users/svn/svnrep/" ssh-dss

This allows users to use a path like "svn+ssh://server-name/project-name" rather than "svn+ssh://server-name/Users/svn/svnrep/project-name".

  • When using ssh with multiple users, in order to prevent file permission issues, each subversion command on the server should be wrapped by a shell script which first calls umask, ie:
    $ cat /usr/local/bin/svn
    umask 002
    /usr/local/bin/svn-real "$@"

So this means you should rename each command and create a shell script wrapper which calls the actual command.

  • Subversion leaves ".svn" directories in each directory that it's managing which causes problems with earlier versions of Interface Builder and EOModeler which delete all of these directories upon save. Make sure you're using the latest version available of each of these tools.
  • If you're developing a Java Client program using Interface Builder, your nib file will contain a java file buried under several directories. Each of these directories contains an ".svn" directory which even the newer versions of Interface Builder delete. In order to correct this problem, you'll have to download and install the "SubversionPalette.palette"; from Even though this is apparently fairly old, it still seems to work (9/2005).

That's it! Good luck and enjoy subversion.