If you open a project that refers to a source tree that is not defi ned on your system, Xcode attemptsto locate the fi le at the same path it used the last time that tree was defi ned..
Trang 1If you open a project that refers to a source tree that is not defi ned on your system, Xcode attempts
to locate the fi le at the same path it used the last time that tree was defi ned If this path is wrong,
the fi le will turn red, indicating that it cannot be located Defi ne the required source tree, then close
and reopen the project to resolve the reference
To redefi ne your source trees, close all projects, redefi ne your source trees, and open the projects
again Xcode resolves the source fi le paths using the new source tree locations
SOURCE CONTROL
Source control systems work by storing the master copies of your project fi les in a repository
A repository is a database of fi les A repository might be on the same fi le system or on a remote
system Xcode might access a repository using direct fi le access or by sending requests over a
network to a source control server Regardless of the confi guration, you interact with the source
control system through Xcode or via a source control client installed on your system
A fi le stored in a repository is called a managed fi le When you want to work with a managed fi le,
you check out the fi le from the repository The copy of the fi le you checked out is called the working
copy If you make changes to the working copy, you later check in the fi le to record those changes in
the repository
After the changes have been recorded, other developers can check out the fi le to incorporate your
changes into their working projects You can compare your working copy with other versions in the
repository to see exactly what has changed You can also check out an earlier version of any fi le and
use it instead — maybe because you don ’ t like the changes made by another developer
Xcode has integrated support for three major source control systems: Concurrent Versions System
(CVS), Subversion, and Perforce CVS was the reigning king of open source control systems but has
since been usurped by Subversion An installation of Subversion is included in the Xcode Developer
chosen for this book over CVS and Perforce for four reasons:
Subversion is, in many ways, superior to CVS — which it was designed to replace
Subversion is less expensive than Perforce (it ’ s free)
Subversion is very popular among open source projects
Subversion comes pre - installed with Snow Leopard and is the de facto standard for Xcodesource control
Trang 2That ’ s not to say that CVS or Perforce are bad choices If you already have a CVS or Perforcerepository, then your best choice is clear
SOURCE CONTROL BEYOND XCODE
You’re not limited to using the source control systems that are integrated intoXcode, and you’re not limited to using your source control system via Xcode
The Git SCM system has attracted a lot of attention lately, and may somedayovershadow Subversion You can use Git — or any other source control system —
to manage your project’s fi les; you just can’t use it from within Xcode (unless yourSCM has a Subversion or CVS emulation mode)
Source control systems also provide many features and commands that Xcodedoesn’t support Xcode’s source control commands focus on common tasks you’relikely to perform during development (check out, check in, compare, merge)
Regardless of whether you use a source control via Xcode, you will still need toreach for your favorite source control client to perform advanced activities likerepository creation, branching, tagging, migration, and fi ltering
Even for those actions that can be performed from within Xcode, you may stillprefer using your source control client or a third-party application For example,when I’m about to release a product I use a third-party Subversion utility forcollecting, organizing, and reviewing the changes made since my last release
Though the same information can be found in the Info window of my project, it’snot nearly as easy to sift through
Using Source Control
Using source control through Xcode can be broadly divided into three phases:
1. Defi ne a repository
2. Check out a project from a repository
3. Use source control from within the project
The next section describes how to defi ne a repository The sections starting with “ BrowsingRepositories ” describe how to view the contents of a repository and check out an Xcode project
Once you have a project checked out under source control, all of your subsequent interaction will bethrough the project, described starting in the “ Source Control Interface ” section
Defi ning a Repository
As mentioned earlier, a repository is a centralized collection of managed fi les Before you can usesource control, you must defi ne the location and characteristics of the repository, or repositories,that you want to use Just like source trees, each developer must create an equivalent repository defi nition if they expect to share the same set of managed fi les The defi nitions might be the same or
Download at getcoolebook.com
Trang 3different For example, you might create a source control repository on your local drive Later,
you decide to collaborate with another programmer and open access to that repository via the
Internet Your repository defi nition would still refer to your local fi le system while his would refer
to a remote repository
All of the repositories you use are defi ned in the SCM tab of the Xcode Preferences (Command+,),
as shown in Figure 21 - 4
FIGURE 21-4
Each repository defi nition has three parts:
The source control client used to access the repository The access method and parameters
A path to the root directory within the repository
➤
➤
➤
Download at getcoolebook.com
Trang 4Click the + button below the list of repositories to defi ne a new repository A dialog sheet willprompt you for a repository name and the client that will be used to access the repository Theclient you choose — SVN, Subversion, or Perforce — will determine what settings are needed
to defi ne the repository The name identifi es the repository defi nition in Xcode and can bechanged later
Clicking OK creates a new repository defi nition Fill in the settings as required What those settingsare is entirely dependent on how the repository was created and where it resides If you didn ’ t set upthe repository, contact the administrator of the repository for the correct settings In some situationsthey may need to create a user account and password for you, or you might have to register an SSH key
For Subversion repositories, the settings to confi gure are:
SUBVERSION SCM SETTING DESCRIPTION
Scheme http , https , file , svn+ssh , and so onHost Host name or IP address of server (for network schemes)Path Path to root directory in repository (may include the path to
the repository itself)
Password Password for user (if required)
The URL setting and the other settings mirror each other Whatever you enter for the other settings is combined into a single URL, and whatever you enter into the URL setting isdecomposed into its individual settings If your Subversion administrator or open source projectprovides an URL to the repository, paste that into the URL fi eld; Xcode will fi ll in the settingsfor you Conversely, if you need an URL to access your repository via the source control client orsome third - party tool, Xcode has already constructed it for you Copy the URL and paste it intoyour client
The path setting defi nes the top - level directory within the repository where this repository defi nition
is anchored You may create a single repository defi nition that points to the top - level directory in therepository, or you can defi ne multiple repository defi nitions that point to individual subdirectorieswithin a single repository Which you choose is a matter of personal preference, style, and anysecurity restrictions that might be in place I tend to defi ne a repository defi nition for each set ofrelated projects, even if more than one set shares a single repository When I browse that repository,
I ’ m not distracted by unrelated directories
The path setting might also describe the location of the repository itself That is, the fi rst part
of the path is the location of the repository database, and any remainder is a path within the
Download at getcoolebook.com
Trang 5repository structure It ’ s not obvious where the path to the repository ends and the path within
the repository begins, but it ’ s usually immaterial
Repository on a Local File System
If you ’ ve created a Subversion repository on a local volume, you can use the fi le scheme to access it
directly Set the following two settings:
Scheme: file Path: /Complete/Path/To/Repository/Subpath/To/Root
The file scheme path defi nes the location of the repository database and must begin with an
absolute fi le system path to the repository database Any remaining path components are interpreted
as subdirectories within the repository
Creating a local repository is best when you need source control for archiving and version tracking
If you plan to collaborate with other developers, you ’ ll probably want to create your repository on a
networked server
If you don ’ t have access to an existing Subversion repository, or just want to get started using
Subversion for your own projects, jump ahead to the “ Creating a Subversion Repository ” section,
and then come back here to defi ne it in Xcode
Repository Access via a Web Server
Subversion repositories designed for wide consumption are often set up behind a web server, such
as Apache Source control requests are made through the web server and passed along to the source
control server This is very common with open source projects If you don ’ t have a URL for the
project ’ s repository, you will need to confi gure the following settings:
Scheme: http or https Host: www.host.net or 10.0.254.1
Path: /path/to/repository/root/directory
Port: alternate port (optional) User: account name (optional) Password: account password (optional) Setting up Subversion to work behind a web server is a non - trivial exercise You ’ re most likely to
encounter this for repositories that have already been created
Subversion Server via a Network or SSH
Subversion supports a couple of its own client/server schemes The svn scheme lets you set up
a Subversion server on a computer and interact with it via a dedicated IP port This is useful for
development groups on a local area network, and is much easier to set up than a web - hosted
Trang 6Subversion server It has the disadvantage of limited security, and the non - HTTP IP port might beblocked by fi rewalls, neither of which are typically concerns on a private LAN
To set up a Subversion server, see the “ Server Confi guration ” chapter of the Version Control with
Subversion book
A less well - known scheme is svn+ssh — also described in Version Control with Subversion
This scheme performs Subversion actions by executing source control client requests on a remotecomputer via SSH The remote computer doesn ’ t need to be running a Subversion server, but it doesneed to be transparently accessible via SSH This usually means that you ’ ve installed pre - authorizedSSH keys for the remote account on the server
Because there ’ s no server process involved, the svn+ssh scheme is easy to set up — not that muchmore diffi cult that setting up a local repository You will also want to install pre - authorized SSHkeys so that Xcode doesn ’ t prompt you for a password or passphrase every time it needs to interactwith the repository If you followed the instructions for setting up remote debugging in Chapter 18,you ’ re already done Security in svn+ssh is excellent, because it ’ s supplied by SSH
The primary disadvantage to svn+ssh is performance; invoking the source control client via SSH isslower than a dedicated server would be Nevertheless, I highly recommend this confi guration forsmall, geographically scattered teams that need secure source control with modest performance andminimal maintenance
Checking Your Repository Defi nition
The repository defi nition pane automatically tests the settings as you enter them A statusindicator at the bottom of the pane shows Xcode ’ s success in using those settings The possibleresults are:
Incomplete Confi guration Authenticated
Error: Description of error The fi rst message means that your defi nition is still missing some required setting or settings
A green “ Authenticated ” message means that Xcode has successfully accessed the describedrepository using your settings Congratulations, you are ready to start using your repository!
A red “ Error ” message indicates that the settings are wrong or that some other confi guration orcommunications issue is preventing Xcode from accessing the repository Read the error descriptionfor clues and carefully review your settings
Source Control Options
Before running off to use your newly defi ned repository, take a quick look at the Options tab of theSCM preferences pane, as shown in Figure 21 - 5
➤
➤
➤
Download at getcoolebook.com
Trang 7I recommend checking the Confi gure SCM Automatically option When you check out a project
via source control, the working fi les are under the infl uence of the source control system — but
the project will not necessarily be confi gured to use source control Turning this option on allows
Xcode to confi gure your project automatically to use source control when it detects that it ’ s
appropriate Otherwise, you ’ ll have to confi gure the project manually as described later in the
“ Confi guring a Project for Source Control ” section
The Save File Before SCM Operations automatically saves your fi les to disk before performing any
source control action (check in, check out, and so on) I recommend setting this option for the same
reasons I recommend setting the Always Save Files option in the Building pane
The remaining options control how fi les are compared in Xcode Most often this is when you want
to compare the working version of your fi le with a different version in the repository Some of these
settings also apply to comparing fi les in snapshots
The Comparisons Handling option selects the application and layout used when comparing two
fi les Xcode will obtain both versions of the fi le and pass them to the application for side - by - side
comparison Your choices are :
FIGURE 21-5
Download at getcoolebook.com
Trang 8Xcode FileMerge BBEdit Other Using Xcode is the fastest, but also the least capable Xcode ’ s built - in comparison window isadequate for comparing two fi les but is awkward if you want to selectively replace individualsections of your working fi les with those from the revision
The FileMerge application is a standalone fi le comparison utility included in the XcodeDevelopment Tools package If you own Bare Bone ’ s BBEdit application, you can use its excellent
fi le comparison interface instead
The Other setting lets you select any third - party comparison tool that accepts two fi lenamearguments and compares them
Xcode can also compare fi les using the traditional POSIX diff tool The settings underDifferencing defi ne some format arguments that Xcode will pass to diff See the diff man page for
a complete description of these settings
Your SSH Certifi cates
If access to your repositories requires a private SSH encryption key, those keys will appear in theSSH tab of the SCM preferences pane
The keys that appear here will be any keys installed in your account ’ s .ssh directory and any SSHkeys in your keychain
You can add security by entering a passphrase for one or more keys Xcode will prompt you for thisphrase whenever it needs to use the selected SSH key Leave the passphrase fi eld empty to bypass theprompt
Creating a Subversion Repository
If you ’ re setting up Subversion for your own personal use, or just want to try out source control, thesimplest solution is to create a local repository The following Terminal command creates an emptyrepository named Subversion in your Documents folder:
svnadmin create ~/Documents/Subversion
Now go to Xcode ’ s SCM preferences pane and create a repository defi nition, as described in the
“Defi ning a Repository” section For the example given, your settings will be:
Client: Subversion Scheme: file Path: /User/ youraccount /Documents/Subversion You can elect to use a different repository name and location as you see fi t Note that you can ’ t use auser - relative path ( ~/Documents/ ) in the repository defi nition setting
Trang 9Filtering Out Noise
Ideally, your source control repository should contain only the fi les needed to build your project
This includes your project document, source fi les, resources fi les, and so on It should not contain
any intermediate products (object fi les, compiled data models, help indexes), superfi cial fi les (code
sense index, disassembly fi les), or any fi nal products (applications, bundles) There are a number of
techniques for excluding these so - called noise fi les from your repository
The “no products” rule isn’t universal Repositories are sometimes used to store
fi nished products This is particularly true of frameworks, libraries, and other products that are source fi les for other projects A fi nished framework that’s used
by a large number of developers can be checked into a repository and treated like any other immutable project resource This spares the project from having to check out, and maintain a dependency on, the project that produces the framework.
Xcode ’ s default folder organization conveniently places all intermediate fi les, project indexes, and
products inside the project ’ s build folder Wow, that makes it easy! All you have to do is leave the
build folder out of your repository and 98 percent of your noise fi les have been eliminated There
are basically two approaches to this, and which one you take determines whether you address other
noise fi les at the same time
Omitting the build Folder
The simplest technique — as long as you consistently remember to do it — is simply to leave
the build folder out of repository With no build folder in the repository, your project ’ s build
folder will not be a working folder (that is, managed by source control), and the source control
system will ignore its content To accomplish this, make sure the project has no build folder when
it ’ s fi rst imported (see the “ Adding a Project to Source Control ” section) Do this by either:
Closing the project and deleting the build folder before importing it into the repository Redefi ning the location of the build folder so that the intermediate fi les and products arewritten to a location outside the project folder
Either of these will eliminate the build folder from the project when it is imported, so there will
be no build folder in the repository After that, just be careful not to do anything that would
inadvertently add or import the build folder
Excluding the build Folder
A more rational approach, in my mind, is to confi gure Subversion so that it automatically ignores
the build folder Once that ’ s done, you don ’ t have to think about it Whenever you import a project
or check in fi les, Subversion will automatically ignore the contents of the build folder To do that,
set Subversion ’ s global - ignores property in the ~/.subversion/config fi le An excerpt of my
~/.subversion/config fi le is shown here:
### Set global-ignores to a set of whitespace-delimited globs
### which Subversion will ignore in its 'status' output
# global-ignores = *.o *.lo *.la #*# *.rej *.rej *~ *~ #* DS_Store
global-ignores = DS_Store build *.mode* *~.nib *~
➤
➤
Download at getcoolebook.com
Trang 10I commented out the default defi nition of global - ignores and replaced it with my own The
global - ignores property is a space - separated list of fi lename patterns (globbing) that Subversionwill exclude/ignore on your entire system The patterns I defi ned exclude the following:
PATTERN FILE DESCRIPTION
.DS_Store The hidden .DS_Store fi le used by Mac OS X to manage the appearance of
folders in the Finder build Any fi le or folder named ‘ build ’
*.mode* Window position, toolbar, and other superfi cial layout information stored
per - user inside the project document
*~.nib Backup .nib fi les created by Interface Builder
*~ Generic backup fi les created by some editor applications
These patterns automatically exclude all intermediate, product, and noise fi les from my repository
The hazard of setting an exclude pattern like “build” is that you might someday encounter a project that has a subdirectory named build that contains source
fi les It’s unlikely, but if it did happen Subversion would dutifully ignore that folder too, probably to the detriment of the project.
You can confi gure per-folder fi lters in Subversion These can add additional ignore rules for a specifi c project or override the global rule See the Version
Control with Subversion book for the details
Excluding Other Noise Files
Generally, noise fi les are fi les that are not signifi cant to building the project It ’ s not that they don ’ t containany useful information, but deleting them won ’ t affect the build The advantage of checking noise fi lesinto source control is that they often contain information that you want to preserve or share When
I check out a project, it would be nice if that project remembered all of my settings and preferences
The disadvantage is that noise fi les tend to change often The source control system will want you tocheck any modifi ed fi les back into the repository along with a change comment This often results
in many revisions to the repository that don ’ t represent signifi cant changes to the project This can
be annoying to other developers who must constantly wade through repository changes that have noreal impact on their work
The noise fi les I exclude are .DS_Store and the *.mode* fi les found inside the project document
These are classic noise fi les because they store window position and other ephemeral layoutinformation that has little bearing on my workfl ow If I export a project, and it doesn ’ t save the size
of the project window, it won ’ t cause me any grief
The noise fi les that are most contentious are the per - user *.pbxuser fi les stored inside the projectdocument Each user .pbxuser fi le stores preferences and other settings for that developer, such as
Download at getcoolebook.com
Trang 11breakpoints, smart groups, and bookmarks If you ’ ve worked on a project for a signifi cant amount
of time, this can represent a lot of customization that you might not want to lose when the project
is checked in On the other hand, every time you set a breakpoint your project document will have
appeared to have changed, which can result in a lot of extraneous project document updates that
other developers must deal with
As a rule, the more developers working on the same project the more problematic noise fi les become
You and your other developers will have to decide whether the noise is worth the extra data
Browsing Repositories
Once you have one or more repositories defi ned, you can open the Repositories window by choosing
the SCM ➪ Repositories command The repository window, shown in Figure 21 - 6, is where you can
browse the content of a repository, perform some maintenance, and where you will ultimately check
out a project under source control
FIGURE 21-6
On the left are the repositories that you ’ ve defi ned Select one and the browser in the upper pane
will let you navigate through the most recent content of each repository directory The lower
pane shows a running log of the actual SCM commands that Xcode is issuing in order to perform
whatever actions you request
The Reload toolbar button re - fetches the information from the repository and refreshes the
display The Confi gure button jumps to the SCM pane of the Xcode preferences — the one you ’ ve
been using in the previous sections
Download at getcoolebook.com
Trang 12You don ’ t typically spend a lot of time in the repositories window The signifi cant actions you ’ llperform here are checking out and importing/exporting entire projects, which are all described insubsequent sections Once you do that, almost everything else is done through the project
The repository window does provide a basic set of repository commands Besides perusing thecontents of a repository, you can:
Create a new repository subdirectory Copy a repository fi le or directory Move (rename) a repository fi le or directory Delete a repository fi le or directory
These commands are all self - explanatory Just remember that you ’ re modifying the content of therepository, not the fi les in your fi le system
While the command set looks simple, there ’ s actually a lot you can do with it If you ’ ve taken time
to skim the Version Control with Subversion book, you already know that Subversion doesn ’ t
use metadata (a.k.a., tags) to demarcate releases or branches Instead, it uses a convention ofsubdirectories The main development fi les are stored in a trunk directory Releases are defi ned
by copying the entire trunk into a subdirectory of the tags directory Similarly, copying a projectfolder into a branches subdirectory creates a branch Thus, tagging milestones and branching aresimply matters of copying one repository directory into another
Speaking of subdirectory conventions, if you ’ ve just created a new Subversion repository for a singleproject, you ’ ll want to start by creating a trunk subdirectory, as shown in Figure 21 - 7 You cancreate tags and branches directories when you need them
Trang 13When you create the subdirectory, Xcode prompts you for a comment Every change to the
repository is recorded, annotated with an explanation that you provide, and no information is
actually destroyed Deleting a repository folder doesn ’ t delete it from the repository; it simply
means that, in the most current version of the repository, the directory no longer exists Its previous
incarnations are still, and will always be, available
If you plan to store multiple projects in a single repository, I recommend creating top - level folders
for each project, and then creating trunk , tags , and branches subfolders within each project folder
Other developers prefer to create single top - level trunk , tags , and branches directories
and then have subdirectories for each project within those There are advantages and disadvantages
to each Consult the Version Control with Subversion book before embarking on any major
repository design
Adding a Project to Source Control
So far, you ’ ve created a repository, defi ned it in Xcode, and can browse the repository in the
repository window Now you want to place your project under source control The basic steps for
putting a project under source control are:
1. Create the project
2. Import the project into the repository
3. Check out the project under source control
4. Confi gure the project to use source control
The fi rst two steps are required because placing a project under source control presents a bit
of a chicken - and - egg problem; a project can ’ t be under source control until it ’ s been checked
out of the repository, and it can ’ t add fi les to a repository until the project is under source
control To get around this conundrum, you begin by importing a project into the
repository
Importing takes a project folder — actually any arbitrary fi le or folder — that is not under source
control and adds it to the repository You can do this with anything at any time, but the most
common reason is to get a project into source control in the fi rst place
In the repositories window, select the repository directory where you want the project folder copied
into the repository, or select just the repository to import it into the repository ’ s root directory
Click the Import button in the toolbar and choose the project folder to import, as shown in
Figure 21 - 8
Download at getcoolebook.com
Trang 14Click the Import button and Xcode copies the entire project directory into the repository as
You might think that all you have to do now is fl ip a switch in the project and start using sourcecontrol, but you ’ re not there yet You must now check the project back out of the repository — only
then do you have a set of working fi les that are under source control
Checking Out a Project
Checking out a project (or any set of fi les) from source control creates a working copy of themanaged fi les in the repository Working fi les are special The source control system maintains
FIGURE 21-8
Download at getcoolebook.com
Trang 15additional information about the fi le and its relationship to its managed counterpart in the
repository Before you can use source control from within an Xcode project you must fi rst check the
project out
Somewhat counterintuitively, you must check out your project to someplace other than its original
project folder Either checkout the project to a new location, or fi rst trash, move, or rename the
original project folder I wouldn ’ t delete it yet — just in case something goes wrong
In the repositories window, select the repository folder you want to check out If you want to check
out the entire repository, select only the repository Click the Checkout button and select a location
where the working project fi les will be written, as shown in Figure 21 - 9
FIGURE 21-9
The default name for the enclosing folder will be the repository or folder you ’ re checking out If you
want to change it, do so now The reasons you might want to change it are varied, but one common
reason is that Xcode and traditional Subversion repositories don ’ t use the same directory structure
In an “ old school ” Subversion repository, a project folder named MyProject would appear in the
repository as /MyProject/trunk , /MyProject/tags , and /MyProject/branches When you check
out trunk , the folder “ trunk ” becomes the project folder This is probably not what you wanted
The solution is to check out trunk from the repository, but rename it to MyProject before clicking
Checkout
Download at getcoolebook.com
Trang 16HOW SOURCE CONTROL MANAGES WORKING FILES
When you check out a set of fi les from a repository, the source control system writesadditional metadata about each fi le This includes information like:
The location of the managed fi le in the repositoryThe revision number of the working fi le
A copy of the original fi leStatus and historyThe presence of this metadata is what allows source control to track and managethe working fi les; this is what it means to be “under source control.”
In a Subversion system, this information is stored in invisible .svn directories thatyou’ll fi nd in every folder of your working project As a rule, don’t delete or other-wise disturb these hidden directories Their integrity is crucial to the smooth opera-tion of the source control system
➤
➤
➤
➤
All of the fi les in your project have now been checked out, and all of the working copies of those
fi les are under source control You can now skip ahead to the “ Confi guring a Project for SourceControl ” section
Exporting a Project
Exporting a project is the inverse of importing one, and is the complement to checking one out Exporting a project produces copies of the managed fi les in the repository, but does not createworking fi les In other words, it simply copies the fi les in the repository to your local drive without
any of the source control metadata required to manage them An exported project is not under
Similarly, you might be working on version 1.6 of your application and need to build version 1.2
If you have no intention of creating a new branch or reviewing changes, simply export the projectfrom the 1.2 tag directory into a new folder and build it
Confi guring a Project for Source Control
The last step is to confi gure the project to use source control Open the Info window for theproject group, choose the Project ➪ Edit Project Settings command or choose SCM ➪ Confi gureSCM for this Project At the top of the General tab, you will see the Roots and SCM settings, asshown in Figure 21 - 10
Download at getcoolebook.com
Trang 17This portion of the project ’ s Info window describes the project’s name, location, and the roots of the
project The project roots is a list of directories that encompass the assets of the project For most
projects, everything is contained within the project ’ s folder, which appears in the list as < Project
File Directory >
Because you just checked the entire project out from source control, the fi rst order of business is
to enable source control for the project folder Click the Confi gure Roots & SCM button A sheet
appears listing all of the roots of this project and the source control repository each is associated
with For now, all you are interested in is the repository for your < Project File Directory > If
the Confi gure SCM Automatically preference is on and Xcode was able to unambiguously determine
which repository the project came from, the repository for your project may already be confi gured
If that ’ s the case, you can skip to the next section and start using source control from within your
project
If SCM has not been confi gured for your project, do so now First, select the source control
management system you ’ re using from the pop - up menu at the top of the sheet All of your project
roots must use the same source control system For example, you can ’ t have one root managed by
Subversion and another by Perforce
Now select the repository from where your project was checked out, as shown in Figure 21 - 11
Here, Xcode plays matchmaker; it compares the source control information in your working
directories with the defi nitions of your repositories, and suggests which repositories appear to be
valid choices
FIGURE 21-10
FIGURE 21-11
Download at getcoolebook.com