Re: More complex Subversion usage question
Re: More complex Subversion usage question
- Subject: Re: More complex Subversion usage question
- From: Jack Repenning <email@hidden>
- Date: Sat, 21 Apr 2007 11:27:25 -0700
On Apr 21, 2007, at 9:01 AM, Blair M. Burtan wrote:
How does Xcode deal with a project whose components come from multiple
Subversion repositories?
XCode itself doesn't support this, you'll have to hand-craft the
working copy on its behalf (as, indeed, you do even for a simple
project). There are several ways to do this.
At the simplest level, you can check out each file set into a
separate directory tree, and import files into the central project,
unchecking the "copy if necessary" box. More likely, your "external"
components are structured as Frameworks, and the Framework process
also allows an "import without copy."
Either of these arrangements, however, will still require you to do
your version control from the particular project where the files
actually reside, which may not be what you wanted (or it might; all
depends on your process for co-maintaining these components). To
incorporate the files so XCode handles them all as a single project,
your choices are the Subversion "switch" command, or the
svn:externals property.
For clarity, let's say your plan is to create a project at
~/src/MyComplexProject/
This will have such familiar contents as ~/src/MyComplexProject/
MyComplexProject.xcodeproj.
You also want some stuff from the other repository "otherrepository"
to live at
~/src/MyComplexProject/OtherStuff/
so there might be, for example,
~/src/MyComplexProject/OtherStuff/OtherStuff.xcodeproj
(if OtherStuff is in fact a well-formed XCode project in its own right).
With "switch," the process is something like this:
1. Craft MyComplexProject to include an empty "OtherStuff" directory,
where you intend the sub-project to live. Check in this structure
(including the empty directory -- "svn add" it, but not anything
below it.
2. At the command line (something like your step 4 in your "using
Subversion, XCode, and SmartSVN" posting), cd into OtherStuff and use
"svn switch" to populate the directory from the other repository:
cd src/MyComplexProject/OtherStuff
svn switch svn://localhost/svn/otherrepo/trunk/OtherStuff
With svn:externals, the flow is slightly different:
1. Craft MyComplexProject *without* that OtherStuff.
2. On the directory MyComplexProject, set an svn:externals property
that points to the other repository and gives it the name OtherStuff
svn pset svn:externals "OtherStuff svn://localhost/svn/otherrepo/
trunk/OtherStuff" .
3. Check that in
Which approach is best for you? Either of these approaches produces
a directory three that XCode thinks is a simple, single tree, so all
XCode's functions work naturally, not inconvenienced by the
boundaries. Perhaps the most important difference is what happens if
there are several people using this arrangement: one of these tricks
is only in your working copy (and is therefore entirely private to
that user and directory tree), while the other is stored in the
repository (and is therefore shared by all users and working copies).
The switch trick is not stored in the repository. On the one hand,
if you have several people working the files, each with different
switch needs (say, different versions of OtherStuff), then each can
do their own switch, as appropriate. The flip side of that liberty,
of course, is the constant necessity to actually do that switch,
whenever you set up a new working copy; most people who go with a
switch-based approach end up writing a script to create the working
copy.
On the other hand, the svn:externals thing only has to be set up
once, and then it is stored in the repo, so you might not ever have
to mess with it again. But it's the flip side of the same coin as
above: the freedom to ignore it has the cost that you *must* ignore
it: you can't flip it back and forth at will, nor have different
people using different versions -- at least, not without a lot of
tricky conventions and support (like "you can point the svn:externals
somewhere else temporarily, but you must remember to revert that
before you actually commit anything").
A final note: all of these approaches leave you, to some extent,
dependent on the health of several Subversion repositories.
Somewhere you've said that you're just using local repositories, so
this isn't a real problem for you. But if and as you grow to use
network repositories, used by several people, and hosted on several
servers, you may run into the problem that the reliability of the
total system is only the intersection of the reliability of the
component parts (the servers): every time you add another server to
the mix, you _reduce_ your real up-time (the time when you can, for
example, update or commit). So long as your servers are reasonably
local, reasonably under your control, and reasonably well managed,
this is probably not an issue. But if you start incorporating
components from repositories out of your control, subject to network
outages, system maintenance, and the like, and *not* subject to your
development process needs, it can become a real pain. In these
circumstances, the best advice is to import selected versions of the
external stuff into your own repository, keeping a pristine copy of
whatever you imported on a branch (what is called a "vendor branch"),
but working the files from your own trunk. In this way, if you find
you must change these imported files, you can keep track of which is
which, and ultimately provide good patches back to the original
author, and accept updates from him without creating irresolvable
merge conflicts.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden