[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: Bruce Atherton <bruce_at_callenish.com>
Date: 2003-06-04 19:48:41 CEST

At 11:08 PM 6/3/2003 -0700, John Locke wrote:
>Well, there's the example of the svn update command to emulate--I don't
>see that it needs to behave any differently.

The purpose of the svn-specific URL syntax is to provide a way to uniquely
identify a resource. You seem to think that only the file represents a
resource, but DeltaV's specification (which Subversion is trying to get
closer to) makes the revision a resource as well, called a "Version Resource".

None of this has anything to do with the "svn" application or its update
command, save that the client will probably need to support the URL syntax
at some point.

>I see your point, but this is an implementation detail. Seems to me that
>if you actually want to see an earlier version of a file, then you ought
>to be able to put together a simple URL with a query string to do it.

A simple URL, yes. But why insist on a query string? There are other ways
of accomplishing the same thing.

>Again I see your point, but I'm coming at this from a user perspective,
>not a developer perspective.

As a user, how is this:

     http://my.svn.org/project/branch/file.c?rev=1010

different from this:

     http://my.svn.org/project/branch/file.c;rev=1010

The first says that the resource is "file.c", and that a query is applied
against that resource. The second says that the resource is "file.c with a
parameter of rev=1010".

>I just hope that any URL scheme the project chooses to implement for
>accessing different versions in the repository follows existing
>conventions, rather than creating new ones. And being a web developer, I
>prefer web conventions...

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 4 19:49:40 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.