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) …

Today I received a box containing the replacement PC for my wife. I got a really great deal on a refurbished HP Desktop with a quad core AMD processor, 8Gb of memory and a 750Gb drive from TigerDirect.com.

I’d been waiting about a week for it to get here, and my poor wife has been limping along on my slowly dying laptop in the meantime. I suspect that it’s about to die, as it has become painful just to start up a browser or read email.


The UPS lady arrived at my door shortly before 5pm, and told me that she had heard a crash from the back of the truck in the morning. At first she thought someone had been drinking in the truck: she smelled beer.

As it turned out, a box containing beer had fallen and was leaking in the truck. She showed me the bottom of my package was wet, and said I could refuse the shipment and have her take it back.

I figured that it would probably be OK, since they usually pack things like desktops pretty well (in plastic and foam), so I asked her if I’d be able to send it back after looking inside. She told me that she could come by tomorrow and pick it up and gave me her supervisor’s number.

I opened the box and found that there didn’t appear to be any dampness or liquid inside (so far so good). But then when I actually pulled the desktop out, the front panels were all poked out, and the Styrofoam pieces were broken.

Now I figured that it would be just my luck that it would work initially and then start having weird problems caused by having been dropped. So I decided to send it back, and I called the number the UPS lady had given me.

Her supervisor told me I had to call the shipper and have them make a claim, that they couldn’t return the box once it had been opened. So I called TigerDirect to get a return label and see if they could ship a replacement.

The return part was easy, they sent a link to my email. Interestingly enough though, during the order process, they had offered me a $5 discount for using Google Checkout, and that meant they couldn’t just ship a replacement out. The customer service rep told me they could process a new order and give me free next-day shipping, but it would require a new order.

After looking at the inventory, the machine I had ordered was the last one of that model, and they offered me something that looked similar in price. I looked at the things that were available and decided to wait, so I’m back on the hunt for my replacement desktop.

Maybe somebody is trying to tell me something, this hunt for a new computer has been painful, maybe I should just look for another Mac