[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn:externals Are checkouts atomic?

From: John Szakmeister <john_at_szakmeister.net>
Date: 2005-01-28 10:49:59 CET

Scott Palmer wrote:
> On Jan 26, 2005, at 11:27 AM, Ben Collins-Sussman wrote:
>> 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).


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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.