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

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

From: Holger Stratmann <tigris_at_finch.de>
Date: 2005-08-26 12:05:39 CEST

Romain Prévost wrote:

>I may be wrong,
>
And I think you are ;-)

>but properties are not versionned in SVN.
>
Is that true?
I think that "revision (!) properties" are "not versioned".
The externals-definition is a "directory-(/file-)property". How can I
even change that after the commit?

>Therefore,
>if an external reference breaks in your repos, change it's property,
>delete it, whatever, and all will be fine for the the whole history.
>
>I don't know about specifying a particular revision for the external
>property, anyway.
>
Neither did I - only after people mentioned it on the mailing list did I
notice the little "-r21" in the book :-)

So yes, it IS possible...
(I guess I'll still prefer using tags and/or branches for that purpose...)

... BUT it doesn't change my question a bit: What if the SERVER ADDRESS
changes?

Holger

>
>
>
>2005/8/26, Holger Stratmann <tigris@finch.de>:
>
>>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 12:07:33 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.