On 15.02.2018 16:54, Thomas Quinot wrote:
> * Philip Martin, 2018-02-15 :
>
>> That looks correct so far, but it leads me to consider port numbers.
>>
>> svn ls svn://hostname:3691/repo
>>
>> Should the server look for the repository under 'hostname:3691' or under
>> the plain 'hostname'? I suspect the port number should be ignored and
>> that the plain 'hostname' is correct and that makes the current
>> behaviour another bug. We might be better off using apr_uri_parse()
>> rather than writing our own parsing code here.
> Thanks for your feedback Philip!
>
> I also thought about port numbers, and I think that's a different
> situations. I would view URLs differring only in the user name:
> svn://svn.example.com/
> svn://foo@svn.example.com/
> svn://bar@svn.example.com/
> as "clearly" referring to the same server/repo in all three cases.
Yes.
> On the other hand, I can see legitimate use cases where:
> svn://svn.example.com/
> svn://svn.example.com:3691/
> would refer to *different* servers/repos, in which case it makes sense
> to *include* the port number in the path when operating in virtual host
> mode.
Only if the port number isn't the default svn:// protocol port. If it
is, it should resolve to the same virtual host.
> Conversely, in use cases where the intent actually is for both
> URLs to denote the same underlying server, one can use a
> symbolic link svn.example.com:3691 -> svn.example.com.
You can't use symbolic links on all platforms, so that's not a solution.
Nor can you use a colon in directory names on all platforms, so the
vhost directory naming is a bit tricky here.
-- Brane
Received on 2018-02-15 18:09:02 CET