Database Reference
In-Depth Information
Figure 2-3. Tom's project with the new XIB file
At this point, everything is in place for hilarious hijinks to ensue. Let's say that Diane
checks her new code into CVS first:
Diane$ cvs add BuggyWhipChat/BuggyWhipChat/TwitterAPI.*
cvs add: scheduling file `BuggyWhipChat/BuggyWhipChat/TwitterAPI.h' for addition
cvs add: scheduling file `BuggyWhipChat/BuggyWhipChat/TwitterAPI.m' for addition
cvs add: use `cvs commit' to add these files permanently
This isn't the whole story though, because if Diane commits now, she'll be also com-
mitting changes to a local file that got silently modified when she added those class files
to Xcode. A
cvs status
invocation tells the whole story:
cvs status: Examining BuggyWhipChat/BuggyWhipChat.xcodeproj
===========================================================
File: project.pbxproj Status: Locally Modified
That pesky project file has also been modified, since it keeps track of which files are
associated with which targets in the project. If Diane did not commit the changes to
the file, anyone else checking out the project won't see the new class in their project
view, even though the files will physically be on the disk.
Let's say that Diane has done this enough times that she remembers to commit the
project file. We're not out of the woods yet! What's going to happen when Tom wants
to commit his new XIB file? Being an experienced CVS user, he's going to start by doing
a
cvs update
:
cvs update: Updating buggywhipchat/BuggyWhipChat/BuggyWhipChat.xcodeproj
1.1.1.1
retrieving revision 1.2
Merging differences between 1.1.1.1 and 1.2 into project.pbxproj
rcs merge: warning: conflicts during merge
Well, that's no fun at all…not only do you end up with a merge conflict, but because
of the way CVS does merges, you end up with a broken project file (which is likely to
