XCode 3’s SCM makes me sad.

Posted by Nick on July 7th, 2008 filed in Apple, OS X, Programming

I just finished trying to use XCode 3’s built in support for Subversion. It did not end well.

For starters I created a new XCode project, ran it to make sure it could build, and then decided to check it in to svn so that I would have a “clean” starting point in case I ran into problems. This is how I normally work in other IDE’s, and I’ve never had a problem. Until today.

After setting up the repository in XCode I couldn’t find how to set the project so that XCode would “know” it was under version control (or SCM as XCode refers to it). If you look at the project’s properties, there is a drop down list the lists the available repositories (or it offers to let you set up a new one, which is a nice shortcut). However, the repository I just added is grayed out. After a half hour of trying various “obvious” things I gave up and googled around.

It turns out that XCode can’t create and then check in. The project has to be put into the repository, then checked out before XCode will recognize that it is under source control. Very unusual, but what ever, I decided to play along.  I used XCode’s svn browser (which isn’t half bad) to upload the code, then deleted the project and checked it out.

And right about then is when it became obvious that I was traveling the wrong way on a one way street. Here’s an executive summary of what I found so very, very, very wrong with XCode’s SCM integration:

  1. I had to create the project, check it in, then check it out for XCode to realize that it was under version control.
  2. Although XCode has an svn repository browser that allows me check in and out the code, it doesn’t seem to know anything about XCode projects as it checked in the build directory without asking. For me (and a lot of developers I know) the last thing I want in version control are files that are going to change constantly (i.e. object files). Checking in a finished version, fine. Checking in a ba-jillion intermediate files: fail.
  3. After checking out the project, XCode began complaining about there not being a lock on a file in the build directory. The error message actually said “This might be a bug, please report it.” Sorry Apple, I’m a nice guy, but I’ve got limits. This seems like something that shouldn’t happen on a fresh project (i.e. all boilerplate code, I haven’t done a thing to the project yet).
  4. Deciding that I might be slightly smarter than the computer, I decided to delete the build directory in the repository. I tried to refresh the project to let it know there was a change it might need to be aware of. Instead I was made aware of the fact that there doesn’t seem to be one central view of what’s changed for the project. The near-useless SCM menu item in the project reported that one file had change, and I could not seem to get it to even look at the project as a whole. Maybe I’m spoiled by the way Eclipse handles this situation (which provides a bunch of clues in different areas, but all of which lead to a pretty straightforward GUI for dealing with changes). Even TextMate handles this decently (just not as good looking as Eclipse).

By this time I just gave up. I removed the repository connection from the project settings, and decided to just go Command-line for doing my updates/commits. Life’s too short to be chasing my tail on stuff like this.

Leave a Comment

You must be logged in to post a comment.