On Jan 26, 2005, at 11:27 AM, Ben Collins-Sussman wrote:
>
> 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.
>>
...
>
> Checkouts aren't atomic, and it's not really a problem SVN necessarily
> needs to solve.
I understand exactly what you mean, yet part of me wonders, is it that
much less useful than atomic commits? The two work well together.
> '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.
I'm on Windows where parsing the text output of the svn command and
using that to modify the next checkout is extremely cumbersome,
particularly with the build tool that I'm using (Visual Build).
> 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.
This makes sense, except lets assume that A and B are both under active
development and it could be that using tags would require tagging A
excessively. E.g. A is a new library with an evolving API, it has
never been released yet, methods are being added daily. And B is the
first product that will use that API. Both are being developed at the
same time.
It's certainly non-critical. I just thought I would plant the idea of
atomic checkouts because it seems like something that would be
beneficial if it just worked that way.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 26 20:51:57 2005