Re: Related projects and version control

  • 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.

previous month september 2007 next month
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today