Re-reading my last email on this topic, I find it a bit scattered, and not
very clear.
Also, I've found RFC1808 "Relative URLs".
In light of that, here is a revised version.
Relative externals would be a useful feature, but there is quite a lot of
complexity in defining the extensions to the format of externals
descriptions to accomodate this.
This is because there are potentially four different kinds of relative
externals:
The examples below all consider possible externals on the hypothetical
directory:
http://alpha.example.com/svn/repos1/trunk/module1
1. Directory-relative externals.
Suppose module1 wishes to import module_common. For maximum flexibility of
access method, host, and branching/tagging, the desired externals definition
is:
"common ../module_common"
This is straightforward, and conforms to RFC1808
2. Repository-relative externals.
Suppose module1 wishes to use tagged version 1.0.0 of module_common for its
trunk development, insulating itself from possible instability of
module_common's own trunk development. For the same reasons as above, it is
now desired that the external be specified relative to the root of the
repository.
Is this syntax appropriate?:
"common /tags/1.0.0/module_common"
There are two issues:
a) What about access to sibling repositories? Is this legal?:
"otherlib /../repos_otherlib/trunk"
b) This has defined the 'root' of absolute paths to be the repository root,
which means this is no longer RFC1808-conforming, and has used the '/' root
notation in a not immediately obvious way. Since operating this kind of
relativity requires svn-specific knowledge to split the URL into
to-repository and in-repository components, I feel that nothing would be
lost in departing from URL RFCs, and I propose this modification to the
examples above:
"common R/tags/1.0.0/module_common"
"otherlib R/../repos_otherlib/trunk"
Note that interestingly this doesn't have any special consequences for a
directory named 'R', as you would never use externals to refer to a
directory that was within the directory on which the svn:externals property
was set.
3. Host-relative externals.
I cannot think of a use case for host-relative externals, except possibly as
a conceptually easier if slightly less flexible alternative to reference
sibling repositories.
However, RFC1808 hands us an obvious syntax for implementing it - the '/'
notation I raised and rejected in point 2 above.
Here is the otherlib example rewritten using host-relative externals:
"otherlib /svn/repos_otherlib/trunk"
Note that this hardcodes the knowledge of where in the server namespace the
repositories are exposed ("/svn"), but is rather more intuitive than the
"R/../repos_otherlib/trunk" notation.
4. Scheme-relative externals.
Returning to our module1 example use cases, suppose that module1 now wishes
to use module8, which is being developed by Beta Group within the same
organisation.
Both repositories are visible over both http:// and https:// - but,
whichever you use for the root checkout, you probably want to use for
externals too.
RFC1808 defines a syntax for us to use:
"module5 //beta.example.com/repositories/five/trunk"
Hopefully, you will find this email somewhat efficiently conveys what I am
thinking than my previous on this subject :-)
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 4 02:16:22 2005