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

svn:externals - question: changed (external) hostname => DEAD revisions?

From: Holger Stratmann <tigris_at_finch.de>
Date: 2005-08-26 10:43:57 CEST

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 :-)


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

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.