Subversion Conversion: Upgrading Projects to Xcode 2.1

(See bottom for updates.)

You’ve followed my Subversion posts so far; you have an Xcode 1.* or 2.0 project you’ve checked into your Subversion repository.

Now, you’ve updated to Xcode 2.1, and you want to open your .xcode project.

In previous versions of Xcode, the application allowed you to update your project in-place, which made source control maintenance easy. But now, Xcode will prompt you to “Upgrade a Copy,” and will require you to use a new project suffix, .xcodeproj.

Xcode projects are really folders, a.k.a. bundles. So a project name change means a folder name change. In CVS, this is suboptimal. In Subversion, not so much, but Xcode’s upgrade process complicates matters. Here are the steps that I used:

1) Open the project in Xcode 2.1. Click the “Upgrade a copy” button, and choose a temporary project name, like Temp.xcodeproj.

2) Go to Terminal, type in svn rename MyProject.xcode MyProject.xcodeproj and then svn commit -m "My message" MyProject.xcode MyProject.xcodeproj, where “MyProject” is the actual name of your project, and “My message” is your commit message.

You may need to use svn revert MyProject.xcode/* first to make sure any trivial project changes made during your last 2.0/1.* session, but after your last commit, don’t prevent the rename.

3) Copy all the gunk inside the Temp.xcodeproj bundle to the renamed project bundle. The most important thing will be the project.pbxproj, but there will be other files that start with your or other people’s username and end in various suffixes that you can copy and commit at your discretion.

4) Open MyProject.xcodeproj again. Now, from within Xcode itself, you’ll be able to do the rest of your Subversion commits, namely the project.pbxproj and other myusername.* files. This is most easily done from the SCM smartgroup visible under Groups & Files in the Default and All-in-One Xcode layouts. Select the files, then Control-click them and choose “Commit Changes…” from the contextual menu.

You couldn’t commit them from within Xcode before because you didn’t have the proper .svn folder in the same place as the changed files.

Basically, Xcode wants to be in charge of the project rename, but Subversion also wants to be in charge of the project rename. To satisfy both, you have to do it twice, and then do your own manual (but simple) “merge”.

And you will have to do this for every Xcode project in your Subversion repositories.

The good news is that, once you’re done, your project history will remain uninterrupted.

Update #1: One thing that doesn’t work is changing the suffix to .xcodeproj first and then opening the project in Xcode 2.1. The Xcode UI still requires you to upgrade a copy; it will still not upgrade the project in-place.

Update #2: Another way to do this is to skip 2) completely. The resulting MyProject.xcode will still open in Xcode 2.1 fine, and you won’t have to worry about renames in your repository.

The Xcode 2.1 UI doesn’t give you the choice to use the .xcode suffix for the upgraded project, but the fact is all historical suffixes are still valid for 2.1 projects, even .pbproj and .pbxproj. Xcode examines the actual contents of a project to determine whether it needs to be upgraded, not its suffix.

3 comments

  1. Mike Zornek

    I went another route, which seemed more natural (for me).

    Checkout the latest trunk; opened up the project; made a upgraded project file with a copy; then manually added the new project file (a bundle actually); committed the change; deleted the previous project file; committed the change; deleted my working copy and got a fresh one from the repository; seems to work fine.

    Now bear in mind I’m the only one accessing this repository, so perhaps your method is to make sure other people who have checkouts will get the change easier (I’m not sure) or maybe I’m forgetting something. If so please let me know. Thanks.

  2. Andrew Pontious

    The trouble with your method, if I’m following you correctly, is that previous history is not saved.

    Not a massive problem, esp. with smaller or personal projects, but I know I’ve been annoyed to inherit projects where I couldn’t go back and see what the checkin history was beyond a certain point without knowing what the file’s previous name was, going back and checking it out, etc. Big pita.

    Being able to rename and move files in Subversion allows you to keep the history, and is one of the things I love love love about it.

  3. Mike Zornek

    History is as good as any reason to do it your way. Yeah, my stuff is personal so I can be a little more carefree. Thanks for the response.