The book is coming along, but not as quickly as I want. I spent a bunch of time on custom project templates and came to the realization that Xcode 4 project templates were not meant to be created manually. I am not going to put the custom project template material in the book because I do not have enough confidence in the material to put it in print, but I will make the material available online.

The Instruments and Interface Builder chapters are the chapters that have the most work to do. I have been working on the Instruments chapter the past few days and hope to have it ready for proofreading in the next few days.

Tags: xcode book

The book is still several weeks away from being finished. I’m not sure if I can reach my goal of finishing the ebook in May, but if I do reach the goal, it will be late May. I am working on the book every day and making steady progress. When the book is finished, I will update this blog and the book’s website.

Tags: xcode book

I recently put a small project on github as an experiment. The biggest problem I had was getting the project’s README file to look right. Github supports a variety of markup languages, but not RTF (Rich Text Format), which is the file format the Cocoa text system uses. If you supply a RTF file and a github visitor clicks on it, the file is downloaded to the visitor’s computer. I tried supplying a plain text file as a workaround, but github displayed each paragraph as a single line, which is very annoying for the reader.

My solution was to paste my README file in TextWrangler and use the menu at the bottom of the window to tell TextWrangler to treat the file as a Markdown file, which is one of the markup languages github supports.

I saved the file, added it to my git repository, and pushed the commit to github. I clicked the README file in github, and it looked decent, better than the plain text version I tried earlier.

Tags: github, textwrangler

The batteries that came with my Magic Mouse lasted four weeks, which was longer than I expected. I figured they would last 1-2 weeks.

I moved the blog to WordPress. I was able to import all the posts from the old blog and from the even older Blogger site. The comments from the Blogger site survived the import, but not the comments from the other blog. Images are missing from some of the newer posts, but I should have them up soon.

For now I’m using one of the standard WordPress themes. I am working on getting the blog to match the look of the rest of the site.

I moved the blog. Here’s the new blog location.

In a previous post on Xcode 3′s new locations for project and file templates, I said project and file templates needed to be in the following locations:

I installed Mac OS X 10.5 and Xcode 3 last night so I can now answer Xcode 3 questions. As I spend more time with the new Xcode Tools, I will take note of changes Apple made in Xcode 3 and write about them here.

Because I don’t have Leopard yet, I don’t have Xcode 3 so I can’t answer your Xcode 3 questions. You can still ask them if you want, if you don’t mind the response “I don’t know”. Apple has an Xcode mailing list where you can ask Xcode 3 questions as well as questions on other Apple developer tools like Interface Builder.

I will post on the blog when I get Leopard, also known as Mac OS X 10.5.

I recently got one of the new iMacs, and I had to move my local Subversion repository to the new Mac. Getting the repository to the new Mac was a little tricky. Most of the Subversion tutorials on the Internet deal with creating a repository from scratch so I figured an article on moving a Subversion repository to a new computer would help people.

Moving the Repository

Moving a repository to a new computer requires three steps.

1. Dump the repository’s contents to a file.
2. Create a repository on the new computer.
3. Load the repository with the contents of the dumped file’s contents.

Run the command svnadmin dump to dump the contents of a repository to a text file. Navigate to the directory above the repository, and run svndadmin dump.

svnadmin dump RepositoryName > DumpFile

Running svnadmin dump like I just did will write the contents of your repository to a file called DumpFile. Ideally you would dump the repository contents before you get your new computer and copy the dump file to your new computer. But I was able to copy my repository folder to the new computer and run svnadmin dump on the new computer.

After creating the dump file, run the command svnadmin create to create a new repository. Navigate to where you want the repository to reside and enter the following command:

svnadmin create RepositoryName

Now it’s time to fill the newly created repository with the contents of the dump file. Run the command svnadmin load to fill the repository.

svnadmin load RepositoryName < DumpFile

Now you’ve managed to copy the repository over to the new computer.

Changing the Repository’s Path

After recreating my old repository, I opened an Xcode project that was in the repository to see if the version control information was appearing in Xcode. The only information that was appearing was the files’ local revision numbers. There was no information on previous versions of the project’s files.

The cause of the problem was the repository path on the new computer did not match the path on the old computer. I needed to tell the files in the repository the new path to the repository.

The svn switch command accomplished this task. To tell the files the new repository path, move to the directory where the project’s files reside and run the svn switch command using the –relocate option. When using the –relocate option, you first supply the old repository path, then the new path.

svn switch –relocate /Path/On/Old/Computer /Path/On/New/Computer

After running svn switch, all the version control information began to appear in Xcode.