Scott Palmer wrote:
> On Jan 26, 2005, at 11:27 AM, Ben Collins-Sussman wrote:
[snip]
>> 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.
I realize that it may require a little bit of work, but why not put the
revision in svn:externals? If the API is truly changing that often,
you'll want some way knowing which revision B is working against. As
time goes on, you can update the external reference and patch B to match
the interface in one changeset (I believe).
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 28 10:52:28 2005