You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2005/01/04 01:13:54 UTC
Relative externals - take 2
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
Re: Relative externals - take 2
Posted by Max Bowsher <ma...@ukf.net>.
John Peacock wrote:
> Max Bowsher wrote:
>> My example above is the RFC1808 officially defined way to specify a
>> scheme relative URL.
>> I'm really unenthusiastic about deviating from the standard.
>
> You didn't have any problem doing so in your example 2b, though. ;)
Well, I couldn't really not deviate from the standard, when the standard
didn't define *anything* to use in that case, could I? :-)
>> SVK //paths are never used in externals definitions, though, are they?
>
> Well, it's really not the way that SVK operates (since it is intended to
> be a distributed system). For that matter, I think it would be better
> in SVK to create a mirror of the remote repository instead of using
> externals. I don't even know for certain that svn:externals works with
> SVK (or that it doesn't).
>
> I also don't know enough of the internals of SVK to know if this usage
> would cause any difficulties. CLKao does monitor this list, I believe,
> but I've cc'd the svk list to be on the safe side...
Ok.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Relative externals - take 2
Posted by John Peacock <jp...@rowman.com>.
Max Bowsher wrote:
> My example above is the RFC1808 officially defined way to specify a
> scheme relative URL.
> I'm really unenthusiastic about deviating from the standard.
You didn't have any problem doing so in your example 2b, though. ;)
>
> SVK //paths are never used in externals definitions, though, are they?
Well, it's really not the way that SVK operates (since it is intended to
be a distributed system). For that matter, I think it would be better
in SVK to create a mirror of the remote repository instead of using
externals. I don't even know for certain that svn:externals works with
SVK (or that it doesn't).
I also don't know enough of the internals of SVK to know if this usage
would cause any difficulties. CLKao does monitor this list, I believe,
but I've cc'd the svk list to be on the safe side...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Relative externals - take 2
Posted by Max Bowsher <ma...@ukf.net>.
John Peacock wrote:
> Max Bowsher wrote:
>> 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"
>
> Unfortunately, this conflicts with SVK's usage (that's a path in the
> default
> repository). I don't know if this is enough reason to forbid its usage in
> Subversion itself, but there it is...
Ugh.
My example above is the RFC1808 officially defined way to specify a scheme
relative URL.
I'm really unenthusiastic about deviating from the standard.
SVK //paths are never used in externals definitions, though, are they?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Relative externals - take 2
Posted by John Peacock <jp...@rowman.com>.
Max Bowsher wrote:
> 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"
Unfortunately, this conflicts with SVK's usage (that's a path in the default
repository). I don't know if this is enough reason to forbid its usage in
Subversion itself, but there it is...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Relative externals - take 2
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
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