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?
>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
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
>2005/8/26, Holger Stratmann <firstname.lastname@example.org>:
>>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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Aug 26 12:07:33 2005