I've had problems like this as well. But I think that there is no simple
solution -- the range of uses that we would really like to address is too
broad.
For instance, suppose your external link is to another repository. Then the
"same version as" rule doesn't work at all. On the other hand, at one point
I checked out -r{2005-02-10}, which *could* be propagated to other
repositories through external links.
The current situation is not optimal, but it has the advantage that its
semantics are well-defined. And one can always adjust the versions of the
externals in a WC by judicious "svn update -r" commands. In a way, that's
about the best you can do, since any use of svn:external is always going to
create a Frankenstein's monster, made of pieces that are stitched together.
But as John Derby notes, "svn update -r" can't be used to fix an "svn
export".
An idea came to mind about this, and I don't know if it's worth anything:
You can edit the svn:externals in the WC to specify exactly what revision
you want, and then "svn update" won't mess up the files that get included.
The only problem is that you want to avoid checking in that change to
svn:externals. I've noticed a similar problem with other "local
annotations" to working copies: marking a directory "non-recursive", as
well as a host of debugging changes I've made to the file contents. It
seems that there is a need for making a change to a WC that is barred from
being checked in.
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 22 18:00:41 2005