On Jan 28, 2005, at 4:49 AM, John Szakmeister wrote:
> 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).
My description was incomplete. A and B are being developed together in
parallel. A method is added to A because it is immediately needed in
B, or a new code in B is added to accommodate for changes made in A
literally seconds earlier. (E.g. I will often swivel around in my
chair and ask for a change from the developer sitting across the room.)
The whole point is that to build properly you will usually need the
latest versions of both, yet they are changing rapidly so you really
need to be sure to get something that is in a consistent state from the
repository.
It can be worked around manually, but I thought it might not be much
trouble to handle it automatically. If symbolic links were supported
in the repository there would be no need for this at all. For now
svn:externals is already the workaround for not having symbolic links
in the repository, in this particular case anyway.
My suggestion was an attempt at making svn:externals a little bit
closer to an implementation of repository-side symbolic links. In fact
consider this use-case:
I have made 100 revisions in the repository that contains A and B. I
want to check out revision 78 of B, which at the time used A as it was
at revision 78. Since svn:externals does not contain a reference to a
specific revision (to work that way would mean manually changing the
svn:externals property for every commit) When I do:
svn co -r78 svn://repo/B
I will end up with rev 78 of B that contains a subdirectory with rev
100 of A - a totally incompatible version.
I think what I really want is svn:internals that gets an absolute or
relative path from the same repository as it exists at the same
revision.
It seems that this would be a reasonably easy thing to implement
because it builds on what is already available with svn:externals. For
me it solves the problem of symbolic links in the repository
completely.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 28 15:22:36 2005