On Sat, Aug 09, 2003 at 11:18:17PM -0500, kfogel@collab.net wrote:
> Jack Repenning <jrepenning@collab.net> writes:
> > >Jack Repenning <jrepenning@collab.net> writes:
> > >> All that granted, I think Greg's insistence that no notation but the
> > >> defined one "hit the wire" for DAV is proper, and inescapably leads to
> > >> the rest of what I said here. This scheme is the only viable
> > >> candidate. whatever its demerits.
> > >
> > >Why does the thing that goes over the wire in DAV have to look the
> > >same as the thing the user types?
> >
> > In the case where the user is typing into a web browser (the problem
> > that got us started on this discussion, this time around anyway), no
> > Subversion code is involved until you cross the wire to the server
> > side. Is it?
To clarify Jack's point: what this means is that SVN code is not available
to transform a user's URL into a form that matches the model defined by the
HTTP, URI, and/or WebDAV specifications.
In the prior run at this, and in the message that Bruce quoted me, I stated
that the query component does not identify a different resource. While I
don't believe that is true for the *current* URI specifications, the "next"
URI draft/spec *does* specify that a query component can be used to identify
separate resources on the server.
While that is nice from a modelling standpoint, it breaks down for the
relative linking and for the PROPFIND handling, per my previous message.
Thus, using query components still doesn't solve the situation here.
[ for reference purposes, the email Bruce quoted is:
http://www.contactor.se/~dast/svn/archive-2003-06/0166.shtml
]
>...
> The server is also welcome to understand other syntaxes, such as
> ".../!svn/rev/X/...". And clients are free to transform one syntax
> into another, as long as they mean the same thing and the server
> understands both.
Sure, clients can do the transformation, but they might not "know" how to
properly do that, and (certainly) web browsers are not going to be
performing any such transformations.
Further, if you eliminate the "specify rev at end of URL" model, then you
are left with a revision in the middle somewhere. Now you have problems
because the namespace in the middle is not clearly separate from the names
of items that you can commit to that space. For example:
http://svn.example.com/repos/!svn/...
In this case, we're assuming that the repository will not have an item named
"!svn" in the top-level directory. A pretty darned safe assumption. But we
*still* allow for that by providing the SVNSpecialURI directive to alter the
"!svn" string to be anything that the local admin desires. And note that
this definitely complicates the client problem -- they don't know if the
admin has left the default, or configured something special.
But if you want to put a revision number in there, then you're going to need
to worry about repositories that have numbered items in the root. For
example, let's say you have:
http://svn.example.com/repos/53/...
There is a potential conflict between rev==53 and a top-level item in the
repository named 53. Ignore the problem? Or enable some way to configure a
different way to fetch the revision tree? Or maybe you make it more
complicated, and (thus) harder for an item to conflict:
http://svn.example.com/repos/rev=53/...
But now we're getting into the "is this really easy for a human to type into
a browser?" And do we need further configurability "just in case"?
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
Received on Wed Aug 13 09:51:42 2003