Inspired by a
recent post
of Joachim Bondo I decided to rework my versioning scheme for Xcode
projects as well. One of the major drawbacks of traditional versioning is that the so-called
marketing version (Apple slang) is kept twice, once in the project’s Info.plist
file and once in the Git tag that is created after release. This redundancy
is not only inconvenient, but can also lead to mistakes, i.e. forgetting to bump the
CFBundleShortVersionString prior to tagging the new release.
So instead of maintaining the CFBundleShortVersionString we will now automatically
inject the version number from the most recent Git tag into the generated app bundle. This is
actually pretty easy and requires just the following two lines of shell code in a custom
Build Phase:
# Update the CFBundleShortVersionString in the generated Info.plist using the most recent Git tag.# Idea taken from http://tinyurl.com/3usjj9d by Joachim Bondo.# Get the current release description from Git.GIT_RELEASE_VERSION=`git describe --tags`# Set the CFBundleShortVersionString in the generated Info.plist (stripping off the leading "v").
defaults write "${BUILT_PRODUCTS_DIR}/${INFOPLIST_PATH%.*}""CFBundleShortVersionString""${GIT_RELEASE_VERSION#*v}"
To add it to a target in your Xcode project, select the target, then Add Build Phase → Add Run Script,
set the shell to /bin/bash and paste the contents of the script above. Make sure it is run
after the Target Dependencies phase and before the Copy Bundle Resources phase, as shown in
the following screenshot.
It is important to note that this will alter the Info.plist file of the built app bundle,
not the Info.plist in your source tree, so your source tree won’t get dirty
from this operation, and you won’t have to either reset or make another commit which would
create a mismatch between the code you tagged and the code containing the correct version
number. This way the version is stored only in the Git tag (i.e. v1.0.0) and you can
remove the CFBundleShortVersionString from the Info.plist in your source tree.
A nice side effect of using git describe --tags is that if you make a development build,
in-between any Git tagging, you will get a version number like v1.0.0-12-gf181880. In this
case the version was built from a commit identified by the (partial) SHA gf181880 which is
12 commits after the last tagged version v1.0.0. A great way to handle the marking version
of development builds.
Local snapshots for Time Machine is one of the new features in OS X Lion that looks really good on paper. But once you have used your new Lion installation for a few days, you will notice that you are running out of disk space. After some digging around I noticed that the /.MobileBackups folder that is used by Time Machine for local snapshots was at nearly 50GiB, even though the external Time Machine backup disk was connected most of the time. I guess this is done to speedup Time Machine in the common case, and make backups available when not connected to the external Time Machine disk.
Besides the disk space issue, the local snapshots feature also slows down your MBP noticably. You’ll notice that the disk is spinning most of the time, and the file copying performed by Time Machine trashes your caches. Everything feels terribly slow after some time. Thankfully Apple engineers included a switch to turn of the local snapshots feature, tmutil supports a new command disablelocal in OS X Lion. Use the following command to disable the local snapshots feature of Time Machine:
$sudo tmutil disablelocal
Note that it might take some time for Time Machine to cleanup the /.MobileBackups folder.
So I’m trying to get used to OS X Lion
now. One of the first things I noticed was that the Library
folder does no longer show up in Finder by default. Of course that was
rather trivial to fix using the following command:
$chflags nohidden ~/Library
One really nice feature in Lion is that new tabs in
Terminal.app now inherit the
current working directory from the tab from which they were opened - something
I implemented in Xfce’s Terminal
seven years ago, BTW. Looks like this is implemented by parsing the path
displayed in the title bar, which can have unexpected results when combined
with ssh sessions, since the path in the title is actually set
via the (remote) shell. In addition the title bar of Terminal windows
now provides the same handles as the title bar in Finder windows, which is
pretty handy.
Unfortunately Apple decided to kick Spaces and replace it with Mission
Control. This
by itself is not necessarily bad, but now there’s no way to get that two
dimensional workspace layout back, at least until Apple decides
to fix that shortcoming. I’ve also noticed that the order of the workspaces
seems to change under some (obscure) conditions, which is even worse. Maybe
I’m just getting old, but until now I was unable to figure out what triggers
this rearrangement - not what I’d call intuitive.
Update 1: Lion also says bye bye to Microsoft Office for Mac 2004, since
Rosetta is not
available for Mac OS X 10.7.
Update 3: Well, I am old… the fix for that Mission Control feature that
drove me nuts is obvious. In the Mission Control preference pane, disable
the Automatically rearrange spaces based on most recent use option. Even
if I was too blind to discover this earlier, it’s nevertheless a really bad
default. Out of 100 Mac users, how many would their workspaces to rearrange
magically?
Just like almost every other geek on this planet, I’m downloading
OS X Lion from the App Store right
now. Rather slow… but that way I can do a full backup first while
the update is downloading. #lion
on Twitter is already busy discussing the new
release.
In related news: The new MacBook Air
looks really great - especially starting at $999. Finally a real alternative
to the MacBook Pro.
