On Thu, Aug 01, 2002 at 02:19:16AM +0200, Féliciano Matias wrote:
> * add svn_local:// for future use by web browsers, nautilus, ...
And, there is where this whole argument loses touch with me.
If you want a web browser, nautilus, etc to interact with your
SVN repository, you should be using ra_dav not ra_local. So,
this use case doesn't hold much water with me.
Yes, the file:// scheme isn't clear at first to newbies, but the
concept of path info is not foreign to URLs. In HTTP scheme, the
server will traverse until it finds a match in its space and
store the remaining unused part as path_info (Apache stores this in
r->path_info).
My problem with the svn:// prefix is that it implies there is a
scheme and protocol. There isn't. SVN does not define a protocol
for interaction and, IMHO, it never should. That's not the job of
the SCM. SVN should be relying on other protocols for interaction.
By defining a svn prefix, you are isolating yourself to a specific
interaction.
Ideally, a sql server URI for SVN would look like this:
postgres://postgres.example.com:port/svn-dbname/dir/foo
This example is based off of the JDBC urls. SVN would add the
username and password via libsvn_auth. The dir/foo component
are the files in the repos that you want.
What SVN requires is a way to consistently define a path info
component and leave the preceding part up to the implementation
of the ra layer. Then, the ra layer will decide how to transform
the remaining part stored in a canonicalized SVN-specific format
that will then be translated however the ra implementation sees fit.
So, I believe we should define a consistent path info strategy
and leave everything else up to the transport mechanism. I'm
fairly against defining new schemes that would essentially
override existing schemes.
Yes, that means that file:// URLs may not map exactly to what
your web browser would like. But, I think it makes more sense
to have a canonical path-info strategy across ra implementations.
And, if you really wanted to be pedantic, I could support the
usage of:
file:///path/to/repos?path=dir/foo
http://server.example.com/path/to/repos?path=dir/foo
postgres://postgres.example.com:port/svn-dbname?path=dir/foo
But, I think using path info everywhere makes it cleaner and
more precise. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 03:25:28 2002