Re: Related projects and version control
Re: Related projects and version control
- Subject: Re: Related projects and version control
- From: Loukas Kalenderidis <email@hidden>
- Date: Thu, 27 Sep 2007 09:54:20 +1000
On 27/09/2007, at 1:30 AM, Jack Repenning wrote:
On Sep 24, 2007, at 7:49 PM, Loukas Kalenderidis wrote:
D2 wants to use the current STABLE version of Engine1 when they
build App2, rather than the version that's currently in
development. Pretty common version control problem I guess. So say
we have all of these projects in SCM.. how would you guys go about
setting it all up?
You don't mention which version control system you're likely to
use, so providing an answer is slightly more complicated (because
they use somewhat different terms). But the basic approach is: you
make "tag" or "label" in your version control system for the STABLE
version of each component, and you check that out, rather than the
trunk or HEAD version. Since your working copy is based on that
label or tag, you don't see changes being made to the trunk: even
if you do update the working copy, you only get the versions with
your tag/label.
When, as happens sooner or later, you want to change to a different
version (say, there's a newly released STABLE), you need to switch
your working copy to the new version. Again, the concept is pretty
much the same in any VC, but the terms are different. In
Subversion, you would use the "svn switch" command; in CVS, you do
an update specifying the new tag.
Would you check out a copy of Engine1, put it in the project
folder with App1 and make it a dependancy?
Drop copies of the built frameworks into App1 project folder and
link against/copy those?
Something else?
It's not necessary to put the Engine1 check-out into the same
project folder. The essential step is to open an Xcode window onto
Engine1, and a second Xcode window onto App1, and drag the Engine1
project object from its own window into the App1 window. This
makes it available for ordinary Xcode gestures, such as dropping it
into some particular target within App1 to indicate which part
depends on the engine.
Your VC system may provide more direct approaches. For example, in
Subversion, there's a thing called "svn:externals", that allows you
to create a directory in App1 that automatically contains a
specified version of Engine1. Any time you check out App1, you
also get Engine1 automatically. This might suit your needs as
you've described them, but people often find that svn:externals is
less flexible than they'd like -- for example, if you and I are
both working the same project, and your App1 wants the STABLE
Engine1 while I want some new experimental one, svn:externals is
going to try to make us both use the same one. If you're feeling
adventurous (and, of course, using Subversion!), you might read up
on this in the Subversion book, and think through all your needs to
see if it's a good fit.
Thanks for your comments Jack. I would be using Subversion, and I've
used CVS a lot in the past so I know what you're on about :)
Really what I meant by putting the Engine1 project in the same
project folder was, would you have a checked out copy of Engine1 for
each application that was dependent on it? Or rather link each
project to a shared copy of Engine1?
It's all beginning to fall together in my head a bit more now that
I'm thinking about the problem more in terms of version control than
how to link the projects together.
Thanks,
Loukas
_______________________________________________
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