On Tue, 4 Jan 2005, Max Bowsher wrote:
> 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.
>
> 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.
>
Note that we have issue #926 about adding a way to specify URLs relative
to the repo root on the command line. If we want that, we should use the
same syntax. This rules out R/..., which I think is ugly anyway. One
possibility would be to create a new URL scheme for this:
svnrepo:/branches/b
> 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"
>
I think this is the way to go here.
> 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"
>
It is unfortunate that svk seems to have used this for something else. I
think we should use it anyway, if it doesn't impose very big problems for
svk.
BTW, we could use rfc2396 as a reference when discussing URL syntax. It is
more recent and covers both generic syntax and relative URLs. IMO, since
we've once chosen to use URLs, we should stick to the syntax in the
specification. Making /trunk mean something other than something relative
to the root on the host would be a bad idea (as you already pointed out).
Similar for your R/ proposal. If we choose some standard, we should stikc
to it, possibly extending it, but not modifying it if we can avoid it.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 4 22:51:12 2005