[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: RFC: a permanent svn-specific URL syntax

From: Sander Striker <striker_at_apache.org>
Date: 2003-06-05 00:01:29 CEST

> From: John Locke [mailto:mail@freelock.com]
> Sent: Wednesday, June 04, 2003 9:13 PM

> My concern with
> http://my.svn.org/project/branch/file.c;rev=1010
> is that I can't control access to the previous version of resource
> file.c without specifying each and every rev in my <Location> block.
> Whereas by putting it in the query string, Apache ignores it.

Bzzt, won't work. Subversion will still use the special urls, so the
authz argument is out the window.

>> Of course. That is why using a semicolon makes sense. It is already part of
>> the RFC for URLs (as I quoted previously) and it does not abuse the query
>> string by using it in an incorrect way.
> Okay. I admit my ignorance of the standards. I'm a practical kind of
> guy--I just want it all to work. Standard or no, does the semi-colon
> syntax work with access controls that exist today? If so, I have no
> problem with it--just never seen it in use.

Access control is a moot argument.
> I still fail to see why this is an abuse of the query string, though. I
> understand your point about the revision being the primary resource (and
> I agree that that's how it should be, and one of the reasons
> Subversion's better than CVS), we're just arguing semantics of the URL,
> and my point is that there are lots of precedents for the syntax I
> propose, whether it's correct or not, while I haven't seen the syntax
> you propose.

Greg explained this in his reply.

> I'm just saying your way involves implementing something that doesn't
> integrate well with how people would want to USE this feature in real
> life, at least as far as access control is concerned--

And there it is again...

> and what I'm voting for is a shorthand with widespread use (correct or not) that
> should be fairly straightforward to implement (okay, implementation is
> probably a wash here), and uses the existing behavior/expectations
> already set by svn update.

The permanent svn-specific url syntax would be an _additional_ feature.
The other, 'special', urls won't go away. The svn client library won't
use the permanent public syntax, but the syntax it is using now. This
is why the authz argument is invalid.

Then, authorization. This can be implemented fairly simply as discussed

Which has a link to a previous explanation aswell.


PS. Given the confusion introduced wrt authorization I wanted to get that
     cleared up. Please don't continue the thread due to this post.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 5 00:02:31 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.