On Jan 26, 2005, at 10:01 AM, Scott Palmer wrote:
> I have two projects in the same repository project A and project B.
> They do not have a common parent that I can use to check them both out
> in with a single checkout command. Project B depends on A and our
> build process checks out both projects, builds A, then builds B.
>
> I was thinking there is a potential race-condition if changes are made
> to A that B depends on such that if I check out rev R of A and rev R+1
> of B the build will fail.
>
> My first thought was that I could create the illusion that A and B had
> a common parent in the repository such that I could get them both with
> a single checkout and be sure to get the same revision for each,
> simply by using svn:externals to pull them into the same working copy.
> But then it occurred to me that since svn:externals is designed so
> that it can link to entirely different repositories that a checkout
> with multiple svn:externals properties still likely acts as several
> distinct checkouts and it is therefore not atomic.
>
> Is this assumption correct? That sv:externals can not be used to
> group projects into a single atomic checkout, at least not without
> resorting to specifying the exact revision number for each URL in the
> svn:externals property?
>
> If so, I think whenever the relative URL for svn:externals issue is
> being worked on, that this idea of making the checkout atomic when
> possible could be addressed as well.
>
Checkouts aren't atomic, and it's not really a problem SVN necessarily
needs to solve.
'svn co URL' doesn't have to be out of your control. If you (or your
build system) starts out with 'svn co URL-of-B', you'll see a message
at the end that says, "Checked out revision R." You can then check out
that exact same revision of A by running 'svn co -r R URL-of-A'.
That's why the -r switch exists.
Second, if the tiniest change to A affects B, you should probably be
using tags anyway. That is, make B depend on a specific tag of A.
Your build system, or svn:externals, can be set to checkout specific
tags of A. You can re-tag A as needed, and change the dependency
accordingly. This is why we have releases, after all. The best thing
is to say, "B depends on version X.Y of A". If you label releases and
make dependencies on releases (and *not* global revnums), then the two
projects can freely evolve without daily worry of breaking each other.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 26 17:29:58 2005