Re: RFC: a permanent svn-specific URL syntax

Bruce is quite right here. Short summary is: query string is out, and using
the path is in. "Period" :-)

On Wed, Jun 04, 2003 at 10:48:41AM -0700, Bruce Atherton wrote:
> 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".

Exactly. The standards out there specify that a particular revision of a
particular file is a *distinct resource*. That implies it must use a
distinct URL to locate it. Simple as that.

The query component of a URL does not differentiate between resources, so
they cannot be used in this situation.

> 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.

Correct. DeltaV specifies the modelling of the resources, and that directly
implies how we can use a URL.

Although, I'm not sure that we can construct a URL syntax that can be built
by the client. More below.

>...
> >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".

From a user's standpoint, the two are relatively equivalent.

However, from a development/model standpoint, it poses significant problems.
Consider the following:

  http://svn.example.com/project/file.c ("head")
  http://svn.example.com/project/file.c;rev=1
  http://svn.example.com/project/file.c;rev=2
  http://svn.example.com/project/file.c;rev=3

What happens when you issue a Depth:1 PROPFIND against the 'project'
collection? There are two answers here:

1) you get props back for project, file.c, file.c;rev=1, file.c;rev=2, and
   file.c;rev=3. this doesn't scale, nor is it what somebody would expect
   when they simply want to browse the repository using their DAV client.

2) the ;rev=* resources are not WebDAV resources, so they are not returned
   in the PROPFIND. (this is legal, per section 5.2 of RFC 2518) However,
   if those three resources are *not* WebDAV compliant, then we'll have
   oodles more problems than we "solved".

So... as I see it, you cannot mix the previous-revision resources among the
current-revision tree. In fact, I don't even think you can mix anything
because of the implications on the collection membership.

Thus, your URL format for per-revision will always be something like:

  http://svn.example.com/.../REVNUM/path/to/file

The question is what goes in the "..." portion. Today, it is typically (but
not always!) "!svn/bc". But how will a client know to do this?

Right back where we started. Give it up, and have the client use external
tools or know how to do PROPFINDs to locate the proper URL.

> >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...

Your suggestion does *not* obey the standards, however. IMO, that takes
ultimate priority over "conventions". Typically, the conventions came into
being simply from not knowing that standards applied, how they applied, etc.

> 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.

From a pure HTTP/URL/resource modelling standpoint, it would make sense.
When you toss WebDAV into the mix, it blows up :-(

Can we end this discussion for now? None of this applies to 1.0 :-(

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org