Domain of the Bored

If you use version control (and you should), then you're familiar with the pollution that an Xcode build folder can put into your status output:

? build/.DS_Store
? build/Debug/UTI Plist Helper.app/Contents/Info.plist
? build/Debug/UTI Plist Helper.app/Contents/MacOS/UTI Plist Helper
? build/Debug/UTI Plist Helper.app/Contents/PkgInfo
? build/Debug/UTI Plist Helper.app/Contents/Resources/English.lproj/InfoPlist.strings
? build/Debug/UTI Plist Helper.app/Contents/Resources/English.lproj/MainMenu.nib/classes.nib
? build/Debug/UTI Plist Helper.app/Contents/Resources/English.lproj/MainMenu.nib/info.nib
? build/Debug/UTI Plist Helper.app/Contents/Resources/English.lproj/MainMenu.nib/keyedobjects.nib
⋮

Good version-control systems offer a way to ignore any file that matches a certain pattern. In the case of an Xcode project, you want to ignore the build folder and a few other things: .DS_Store files, backup nibs (those Foo~.nib packages that IB creates when you save), etc.

In Mercurial, the way to do that is to create a .hgignore file, and populate it with the patterns you want hg to ignore.

In order to save you repetitive work, here's a .hgignore file, already fully-populated, that you can use when versioning your Xcode-based project with Mercurial:

syntax: glob

.DS_Store

*.swp
*~.nib

build

*.pbxuser
*.perspective
*.perspectivev3

What to do with this file

1. Download it, and save the .bz2 file somewhere such as your Documents folder.
2. cd into the top level of a repository.
3. Extract the file using this command line: bunzip2 < ~/Documents/hgignore.bz2 > .hgignore
4. Add the file: hg add .hgignore
5. Commit it.

Thereafter, not only do you have a .hgignore file keeping your status output clean, but it's versioned, so it's easy for you to track and revert changes to the ignore file over time.

You have a puzzle. When you run hg st, it says one of your files is modified:

hg st                                                              %~/Python/run_tests(0)
M test.py

But when you run hg diff, it doesn't say anything about the file:

hg diff test.py                                                    %~/Python/run_tests(0)
___
                                                                   %~/Python/run_tests(0)

The reason, at least in my case, was that the file's permissions had changed. hg st acknowledges this change exactly the same way it acknowledges a change to the file's contents, but hg diff only shows changes to the contents of the file, not the metadata. Thus, a metadata change only gets reported by hg st and not by hg diff.

While I prefer hg over svn, this is one advantage that svn has over hg. hg only uses one column to indicate the type of change, and shows the same letter (M) for metadata changes as for content changes. svn, on the other hand, uses seven columns, and a metadata change puts the M in a different column.

There's no way to make hg st use the svn st format, but you can make hg diff show metadata changes. The way to do this is to edit your hgrc file and enable git mode:

[diff]
git=True

There are two hgrc files; you can choose to change either or both. You can edit ~/.hgrc (this is what I recommend), or you can edit the per-repository .hg/hgrc file. (There is no .hg/hgrc file by default, so if you haven't created one already, you would need to create it.)

The difference, as you've probably guessed, is that ~/.hgrc sets hg's default for all repositories, whereas the per-repository hgrc changes the setting only for one repository, overriding ~/.hgrc and hg's own defaults.

Once you make this change, the output from hg diff will include metadata information:

hg diff test.py                                                    %~/Python/run_tests(0)
diff --git a/test.py b/test.py
old mode 100755
new mode 100644
___
chmod a+x test.py                                                  %~/Python/run_tests(0)

Every good version-control system has this as a built-in feature.

In the below, $TMP is a staging directory, such as “build”, “/tmp”, or “/Volumes/RAM Disk”. It's also where the final archive will end up.

• svn: Sort of. svn export $TMP/MyProject && cd $TMP && tar cjf MyProject.tbz MyProject
• darcs: darcs dist (outputs a .tar.gz file in the current working directory)
• bzr: bzr export --format=tbz2 $TMP/MyProject.tbz
• git: git archive --format=tar master | bzip2 > $TMP/MyProject.tbz
• hg: hg archive -p MyProject -t tbz2 $TMP/MyProject.tbz