Tag Archives: integration

Security Updates, Xcode & Subversion

In addition to my full time job as a developer, I get occasional opportunities to moonlight as a system administrator.  Recently, we updated our Macs to the latest security patch Apple pushed out – and lo, our subversion integration with Xcode broke.  Sigh.

Back when we were initially setting up boxes for development, I very dimly recall there was some “shell magic” via the Terminal that needed to happen to get all the parts working together.  I think this was largely because Xcode preferred to work with an earlier version of subversion, perhaps 1.4.x – and it was no longer readily available at the time.

None the less, it’s easy to forget all the configuration steps in setting up a developer box – especially stuff that takes only a couple hours to figure out a nearly a year ago.  We’re not yet to Snow Leopard, so our tools may be a little dated: Xcode is 3.1.4 and Subversion is 1.5.5.


After the security upgrade, we fired up Xcode and noticed that there were:

  • No modified files in the project.
  • Right clicking a source file showed only “Get Annotations” in the Groups & Files pane.
  • Viewing the SCM | Repositories dialog (from the main menu) gave an error: 180001 unable to connect to the repository.
  • Even more scary was the Terminal message: svn: Expected FS format ‘2’; found format ‘3’


Unfortunately, determining the solution wasn’t particularly clear.  Doing some Google searches on the error messages produced limited results.  The initial reaction was that something went wrong with the repository, but it was just working!  Running, “svnadmin verify” against the repository produced the File System format error message which was ominous.

The first thought was that perhaps the security patch affected the PATH variable.  Mac OS X ships with an older version of the subversion binaries and maybe we were picking up the wrong one.  On the Mac, various shell variables including your path are set in the .profile file found in your home directory.  A quick in the Terminal showed that /usr/bin was first in the path and /usr/local/bin (home to our newer svn) was last.  No problem – a quick edit and all was better.  Well… not quite.

Adjusting the path restored subversion from the Terminal and even the svnX app.  But, Xcode still stoutly refused to acknowledge the existence of the repository.  Grrr!  But, a step in the right direction and at least our repository was okay.

The breakthrough was trying to “Get Annotations” on a file.  There was a much more descriptive error – “155021 (Unsupported working copy format) please get a newer Subversion client.”  This jogged something loose in my mind and I dimly recall having to change some of the system libraries to get Xcode working with the newer Subversion.

After another quick search I found two other folks reported the same thing (Paul Solt and Blind Genius).  I’ll restate the solution here, but effectively Xcode is dynamically linking with the older Subversion libraries found in /usr/lib.  To work with newer builds of Subversion, you’ll need to create symbolic links to the newer dynamic libraries as follows:

cd /usr/lib

sudo mkdir svn.orig

sudo mv libap*-1.dylib svn.orig

sudo mv libsvn*-1.dylib svn.orig

sudo mv libap*-1.0.dylib svn.orig

sudo mv libsvn*-1.0.dylib svn.orig

sudo ln –s /opt/subversion/lib/*-1.0.dylib .

sudo ln –s /opt/subversion/lib*-1.dylib .

After adding the symbolic links, restart Xcode and things should be back to normal.


One thing worth reverting is the PATH change.  Modifying the search order for executables might be considered a security risk as often 3rd party binaries (particularly shell ones) traditionally reside in /usr/local/bin and you might end up running something unexpected.  Perhaps safer is to create symbolic links to the binaries in /usr/bin, or alternatively command aliases in your .profile to run the correct version.