Database Reference
In-Depth Information
not nearly as bad a problem as adding and removing files, because if you're only editing
a class file, you're not modifying the project file, so you're left with an ordinary merge,
just like in any other language under source control.
However, it's also possible to modify your project file without meaning to. Many ac-
tivities that take place on the project view edit the project file under the table. For
example, if you set
NSZombieEnable
, you've just tweaked the project file. If you check it
in, you're going to end up in merge mayhem. So, a general rule of thumb is, don't check
in your project file on a commit, unless you've added or removed files (or made some
change to the project that needs to be permanent, such as adding a framework).
Luckily, a lot of the things you can change (such as the current build target) are stored
in the user project file, not the project-wide file. These files live in the
xcuserdata
directory inside of
xcodeproj
. There's a separate data directory for each user (
Di-
ane.xcuserdatad
, for example), so you would be unlikely to create a conflict even if the
files did get checked into source control, but there's no reason they should be checked
in at all, so don't. In fact, if you're lucky enough to be able to use XCode's integrated
SVN or git support, it won't even offer to check these files in unless you force it to.
Let's Be Careful Out There
Best practices are great, but they never take the place of diligence and planning. As hard
as you try, if you have multiple people working on the sample iOS project, files will get
broken, builds will fail, and work may get lost.
To some extent, these are the rules of the road when working on iOS. You don't have
Frameworks to let you cleanly divide up work, Xcode is highly dependent on machine-
generated files to manage the project, and none of it was designed to facilitate team-
based application development.
However, going in to the project knowing where the pitfalls are likely to occur is a big
first step toward preventing problems. Nothing, however, takes the place of good com-
munications between team members. Leverage those agile practices, mention during
your standup if you plan to mess around with a frequently touched file. If there are
geographic issues with your team, make sure you have procedures in place for good
hand-offs, so your current state follows the sun as well as your code.
One method of catching problems you may have introduced (before they can fester) is
continuous integration and automated builds. In the next chapter, we'll walk through
the challenges that build automation presents, and see how (relatively) easy it is to get
out of the nightly build game.
