Mark Clements wrote:
> "Hari Kodungallur" <hkodungallur@gmail.com> wrote in message
> news:71907dd90608121332k3d4d1631x99eef3eb0cd7cc8e@mail.gmail.com...
> On 8/12/06, Ryan Schmidt <subversion-2006c@ryandesign.com > wrote:
> On Aug 12, 2006, at 20:38, Mark Clements wrote:
>
>> However, it occurs to me that if we move domains (e.g. to
>> mydomain2.com)
>> then all these old links will be broken! Is there anyway to avoid
>> this,
>> e.g. to use relative links, or to edit historical data after a change
>> (without creating new revisions). I want to be sure that if we
>> need to
>> build Project1 v1.0 in a couple of years (possibly having moved
>> servers)
>> that all the necessary files are still available and are from the
>> correct
>> version.
>>
> You are correct, externals will break if the URL to the repository
> changes. I am not aware of a way to avoid this. I do not know if you
> can easily edit it after the fact, for example by editing the output
> of svnadmin dump. Subversion does not support relative paths in
> external definitions yet; it's an open feature request. Suggest that
> if you change URLs, you then visit all projects where you've used
> externals and update the definitions. Also suggest you pick a URL now
> that's unlikely to need to change. (For example, pick a new hostname
> like svn.example.com, even if you're currently hosting it on the same
> machine as other things; this way you can break it off onto a
> separate machine later should you wish to do so.) This also includes
> deciding what server protocol you're going to use.
>
> Ideally we would like to have the externals point to a relative path or be
> able to edit the external at the server if the server moves. But until then,
> you can checkout without externals (--ignore-externals), edit the
> svn:externals and check-in changes, right?
> ------------------
>
>
> The way I understand it, that will update the head, but old revisions will
> still be broken. Is it possible to use a file:// URL which points to a
> directory that can include the tilde (~) home-dir symbol (e.g.
> file://~/repos/etc), or alternatively to a sym-linked directory (e.g.
> file://home/me/repos/symlinks/etc where ~/repos/symlinks/etc points to
> ~/repos/etc) so that it can be repointed if the server structure changes.
>
I brought this up in another thread recently, that a level of
redirection might be a solution. You could have a repository that is
just a list of projects and their associated SVN repository location.
The client would only need to know where the list of projects resides.
The svn:externals property could be something like
project://ExternalProjectA/tags/v1.1. The value 'ExternalProjectA' would
be substituted with the actual path from the project list database.
Another way could be to create a property at the root of a repository
that is your list of external projects, and use a variable substitution
scheme in svn:externals. For example, suppose you create at the root of
your project repository a property called svn:externalprojects with
these lines:
lib1 http://svn.mycompany.com/libs/lib1
lib2 http://svn.mycompany.com/libs/lib2
This says your project uses two external libraries called lib1 and lib2.
The svn:externals property in a directory in your project might look like:
lib1 $lib1/tags/1.1
When svn:externals sees the '$', it would look up lib1 in
svn:externalprojects. It would then do a parameter substitution to get
http://svn.mycompany.com/libs/lib1/tags/1.1.
I'm sure there are better ways to do this and not having really looked
at the Subversion code I don't know if this is feasible or not, but this
was my first thought.
-- John Waycott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Aug 13 00:13:26 2006