Hi everybody,
I have a little question about externals:
If I define svn:externals lib http://host1/svn/...
and later on, that hostname changes, my externals-definition is "dead".
Well, obviously checking out the externals definition fails, BUT also,
the entire checkout is aborted. How can I "ever" check out such a revision?
(other than "--ignore-externals") What if I have "n"
external-definitions and only 1 is broken?
I am actually asking this *before* adding the externals-definition(s)
:-)) If we have a chance of breaking our entire history, it might not be
a good idea to do this kind of thing - and makes "externals" VERY
dangerous IMHO. You can end up with hundreds of revisions that can never
be checked out again???
Point in question: At the moment, our Subversion server is purely
internal (http://serversomething/), but we'll probably "open it up"
externally pretty soon (https://svn.ourcompany.com/...). If I define
"externals" referencing the internal address, nobody will be able to do
a checkout from outside the office...
Thanks for any insights :-)
Holger
P.S.: Along with all the other feature requests about "svn:externals",
could we maybe reference a revision property in the externals-def?
"svn:externals = lib $libserver$/svn/libs/myproject/tags/..." For
"internal external references" (*g*), relative paths would be fine, but
for "truly external" externals, you could later change the revision
property to the new server address... This is not necessarily nice
behavior for a version control systems, but much better than "broken
revisions". The whole "externals"-stuff is dangerous as it is :-)
Also good, but maybe not as "clean": If the externals-server is
unreachable, the user could be prompted for a new address for that
server... (used locally only for him)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 26 10:45:56 2005