Re: Summary: URL rev proposals

At 2:58 PM -0500 8/8/03, Jerry Haltom wrote:
>Something I have not understood in this entire thread is why a URL
>schema has to be considered to be anything other than a useful additive
>for HTTP GET requests?

Eh?

The presenting problem is a UI problem: how can people type in URLs
that specify complicated version ideas; how can people write scripts
that do the same? As far as that goes, there's no reason any of this
needs to reach the wire: the several protocols already have ways to
specify revision info independent of the URL itself; they could
translate whatever syntax we pick here into such an existing form.

In one case, http:// URLs accessed via WebDAV, we do not have that
liberty, because the "client" is actually a web browwser or an OS
remote mount--code we do not control. So in this one case, we would
need to define syntax that the browser could forward on to the server
side, and the server side would handle. Again, this particular
use-case was the presenting problem (kde). As Greg has pointed out,
there already *is* a syntax defined as part of DeltaV that has
exactly the meaning we're looking for here, so for this one use case,
there seems to be as compelling case for using that. That form, by
the way, is roughly
        http://host/path/to/repo/!svn/rev/37/path/within/repository/filename.foo

Bounce back to overall user experience: it would be very icky to have
this capability with some RA layers and not with others. If you
could do
        svn co http://host/path/!svn/rev/13/dir/file
but not
        svn co svn://host/path/!svn/rev/13/dir/file
        svn co svn+ssh://host/path/!svn/rev/13/dir/file
        svn co file:///path/!svn/rev/13/dir/file
So that's an argument for supporting the user-visible syntax--the
same syntax--for all ra's. ra_dav could just pass it through; the
others might have to parse it out and propagate it some other way.

Now, finally, we're left with some unpleasantness about this particular scheme:
* it's ugly (ok, subjective call I admit)
* it's in the middle (which complicates scripting)
* it's configurable by the repo administrator (vitiating the goal of
reliably predicting it in a script)

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.

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org