Morten Ludvigsen <morten_2ps_dk@yahoo.co.uk> writes:
> OK - I see now. I agree that interoperability should always be the
> prime consideration. I certainly wouldn't want to be the one that
> caused a break of this principle :-) I hereby withdraw my suggestion.
>
> Just one thing: HTTP GET of the head revision IS part of the protocol
> isn't it (ie. "[URL-to-repository-root]/[path]")?
Nope. According to the WebDAV spec (RFC 2518, at www.webdav.org), an
HTTP GET on a public URI that represents a "collection"
(i.e. directory) is totally undefined. Here's the relevant clip:
8.4 GET, HEAD for Collections
"The semantics of GET are unchanged when applied to a collection,
since GET is defined as, "retrieve whatever information (in the form
of an entity) is identified by the Request-URI" [RFC2068]. GET when
applied to a collection may return the contents of an "index.html"
resource, a human-readable view of the contents of the collection,
or something else altogether. Hence it is possible that the result
of a GET on a collection will bear no correlation to the membership
of the collection."
In other words, we can make a GET http://public/directory/resource do
whatever we want. Originally, it used to produce an error. Then one
day we said, "awww... let's at least show the dirents for the
directory in the head revision". WebDAV has no notion of a "head
revision", but we do, so we're using it just to be semi-friendly.
DeltaV, however, *does* have a concept similar to 'revision', so to
see a specifically named revision, you gotta do the
DeltaV-client-dance and know the right steps.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 10 15:41:04 2002