Database Reference
In-Depth Information
Figure 2-7. Making the main project depend on the subproject
Diane can then check her new workspace and project into CVS by adding all the new
files and commit the other ones. Tom does a CVS update, and importantly, reopens
the project using the workspace file. Now both Tom and Diane are working inside a
common workspace, but on different project files.
So what happens if Tom and Diane both independently create new files now? As an
example, suppose that Diane adds a new Objective-C class called
GoogleTalkAPI
, while
Tom creates a new
UIViewController
-based class called
ChatChooser
, complete with an
XIB file. This time, Tom is the first one to add and commit his new files. When Diane
does a CVS update, here's what she sees (in abridged form):
Dianescvs Diane$ cvs update buggywhipchat
cvs update: Updating buggywhipchat/BuggyWhipChat/BuggyWhipChat
U buggywhipchat/BuggyWhipChat/BuggyWhipChat/ChatChooser.h
U buggywhipchat/BuggyWhipChat/BuggyWhipChat/ChatChooser.m
U buggywhipchat/BuggyWhipChat/BuggyWhipChat/ChatChooser.xib
cvs update: Updating buggywhipchat/BuggyWhipChat/BuggyWhipChat.xcodeproj
U buggywhipchat/BuggyWhipChat/BuggyWhipChat.xcodeproj/project.pbxproj
The files that Tom modified (the project file, when he added new classes) and the new
class files and XIB have shown up. Notice that even though Diane has added new files
to her project as well, there's no conflict, because those files were added to the project
file for the ChatAPI project. In fact, once she adds and commits her files, Tom will get
a similar experience the next time he updates:
buggywhipchat Tom$ cvs update
cvs update: Updating ChatAPI
cvs update: Updating ChatAPI/ChatAPI
U ChatAPI/ChatAPI/GoogleTalkAPI.h
U ChatAPI/ChatAPI/GoogleTalkAPI.m
