XCode and Subversion woes

Today I spent an hour or so trying to clean up some iPhone code that I’ve been working on for Carticipate. I found that I was having trouble with the build that I checked out from our Subversion repository for a bunch of different reasons.

The very first one was that the code was built on an older version of Xcode, as well as an older version of the iPhone SDK, and on top of that the build machine was running Leopard (10.5) while I’ve been running Snow Leopard (10.6) almost since the day it was released.

I tend to try and stay as up to date with software as I can, and most of the time it serves me well. In this case, I ran into several very interesting issues. First thing I did was to check out the code using the command line tools for Subversion. After a few false starts, I got the full directory from the server downloaded to my Projects folder.

I opened up Finder, double-clicked on the project file, and got a warning about the file being for an older version of the SDK. Since I had loaded the latest version of the iPhone SDK, it wanted to upgrade the project build files to the new format. I figured that would probably be OK as long as I didn’t forget and check things back in, so I went ahead.

Then hit “build and run” only to get compile errors. Seems a few of the calls on the code that is currently being used in the wild aren’t allowed for the latest SDK. A few edits and no more compile errors, but there’s some other error. By default XCode just shows this little icon at the bottom of the project that shows the number of errors, but you don’t really see the build log. Clicking on the little error icon, takes you to the log, and of course there’s more greek there.

Something about not being able to copy a file from a user directory (one that naturally doesn’t exist on my machine). More web searches and digging around to try and figure out where copies are specified. If you’re OS X centric, it’s really pretty intuitive, it’s hidden somewhere and you have to find the right properties page to update. Finally I find the setting in the build targets, change it to point to an existing file, and everything runs like magic.

Now I notice that on the build machine, there is a Carticipate settings page under the iPhones Settings app, and it looks different than the one that you see if you have a production version of Carticipate from the App store. The one on my machine looks like the production build, so I figure it must be because I’m building for the release target, but switching to the debug target doesn’t seem to change anything.

I stumble around a bit more and find a DebugFiles folder that has the Settings.bundle file with the extra settings on it. Seems like it is set up to copy the file from that sub-folder if I’m building for debug, but no matter what I do, I can’t seem to get it to change. I clean, I build, I switch, I clean, I build, nothing …

Finally just to make sure the files are coming from where I think they are, I edit the root.plist in both Settings.bundles to be different, and … Magic, the debug settings show up. I switch to the release target, and the settings pane changes to the production one. So apparently something in XCode was being lazy, and not copying the file from the DebugFiles folder until I touched it (must use Make under there somewhere).

In the meantime, I see a checkin email from another developer that has the entire build tree being checked in. I dig around on the web some more only to find that the way Subversion is configured out of the box on OS X, there are no default ignores, and apparently XCode doesn’t have any intelligence of it’s own around what it checks in. Turns out there is a  ~/.subversion/config file set up, but the global ignores is commented out so nothing is excluded by default.

By default the global-ignores is commented out, even though it seems to include most everything we would want excluded. I chose to copy the list from somebody else for now, making sure I added one for “build” to exclude that for sure:

[miscellany]

### Set global-ignores to a set of whitespace-delimited globs
### which Subversion will ignore in its 'status' output, and
### while importing or adding files and directories.
# global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store
global-ignores = build *.o *.lo *.la .*~ *~ ._* .DS_Store .Trash* *.pbxuser *.mode*

So all I had to do was remove that build folder from the repository, and give this same change to the other developers … Well, not quite …

After I deleted the folder from the repository, I had the other developer try and check it out. He got these really weird subversion messages that said something was locked. I’ve seen those before, and usually it just means you have to run an “svn cleanup” command to get things back in synch. But in this case that didn’t work, and eventually I found that I had to physically delete the folder on his machine before running the “svn update”.

Oh, and did I forget to mention, the other developer is using an older version of the client, so when trying to update he got this lovely message about his client being too old. We updated to the latest client from the Tigris.org site using the Mac OS X download, thinking that would work. Turns out that this update doesn’t replace the version that comes with OS X (in the /usr/bin folder), so you have to remove or rename that one, and add a symlink to the /opt/subversion/bin/svn executable in order to get the newly installed version to be run at the command prompt.

So with the newly updated checkout, the build worked on all machines, and the repository is fairly clean. Then came the next hurdle, the older machines (running the older version of the iPhone developer kit and therefore XCode) would no longer update the code using the built in subversion client. Found a small message about the version being too old displayed in the status line of XCode, so did some more searching.

Apparently on the older version of XCode, you could tell it which Subversion to use, but at some point, the developer tools started including a subversion library. Still haven’t figure that one out yet, but it looks like it might require some more moving files and setting up symlinks to get it to use the newly installed latest version.

Seems like one thing that I am continuing to learn is that it doesn’t pay to keep your software up to date on a Mac (unless you’re really brave) …