Re: Why svn:// isn't a good idea

On Wed, Jul 31, 2002 at 06:24:35PM -0700, Justin Erenkrantz wrote:
> 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

++1

i agree with everything justin has said here, and it quite clearly
sums up why i don't think we need to switch away from file://

you're trying to solve a problem that doesn't need to be solved,
because it isn't really a problem.

-garrett

-- 
garrett rooney                    Remember, any design flaw you're 
rooneg@electricjellyfish.net      sufficiently snide about becomes  
http://electricjellyfish.net/     a feature.       -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org