Database Reference
In-Depth Information
This isn't some abstract peril. Because of the way my company uses Agile development,
I may be working on multiple headlines at the same time, and I'm not allowed to
promote the code associated with a headline to the QA branch until the headline is
complete. As a result, I frequently have multiple sub-branches of the project living in
separate checked out copies of the workspace on my desktop, and promote and merge
as appropriate. If I had a dollar for every time that I broke the parent build by mis-
merging the project files, I could buy myself a nice dinner.
But at least there's a chance that you can merge project files, since they're vanilla XML.
Let's talk about a real nightmare: language translation files. The espoused best practice
when doing iPhone development is to use
NSLocalizedString
to do all your string look-
ups, and then let
genstrings
autogenerate the translation resource files (which are all
bundled together under the
Localizable.strings
file in your Xcode project). As experi-
enced iOS developers learn,
genstrings
overwrites the old translations every time you
use it, so there are a number of publicly available tools that will do a more graceful
regeneration and merge. My tool of choice is the Python script
localize.py
, available at
As long as you only have a single person dealing with this file, you're OK. But once you
have multiple people all adding strings, or even multiple branches (as in my situation
with multiple branches for different headlines), you're sunk! The big problem you're
going to run into is that the translation files are UTF-16 files, and most source control
systems blithely look at them, and say “Oh, that's a binary file; I have no idea how to
merge it.” So if you have multiple people messing around with your translation strings,
you can end up with a very painful manual merge (or have to use a tool such as
File-
Merge
, which knows how to handle UTF-16 files).
In general, any machine-generated iOS file (XIB files, core data schemas, etc.) is going
to be a headache to merge if you have more than one person mucking with them at the
same time, and the cost of doing it wrong can be very high. So how do you handle
multiple engineer development without going prematurely grey?
Workspaces and Static Libraries
One of the major advancements that Xcode 4 brought with it was the concept of a
workspace. You can think of workspaces as a project composed of projects, and one
of the big benefits of this approach is that each project tracks its files and other settings
separately. What this means is that Diane can add classes to her API project, and Tom
can merrily design UI, without stepping on each other's projects.
You can create a new workspace-based project by simply selecting
File→New→Work-
space
, but assuming that you've already got a project underway, you can turn your
existing project into a workspace-based project by doing
File→Save as Workspace...
Once you have saved your project as a workspace, you can open it by selecting the
xcworkspace
file using
File→Open
.
