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://f...@svn.example.com/ > svn://b...@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
