Branko Čibej wrote:
>Luke Blanshard wrote:
>
>
>>Seems to me we could have it both ways:
>>
>> http://host/some/path/leading/to/file.html;123
>>
>>... for thing-at-the-end, or:
>>
>> http://host/some/path;123/leading/to/file.html
>>
>>...
>>
>>
>I don't think we need this. Remember, it only makes sense to have _one_
>explicit version number per path -- you can't request
>
> http://host/part;1/file;2
>
>because the revision number always identifies a whole tree.
>
Yes, but putting it earlier in the URL means that suddenly we can use a
browser to look at an HTML file with relative links at a particular
version. That's an important part of the discussion here. So with the
form:
http://host/some/path;123/leading/to/file.html
... a relative link in this file to "../../images/brane.gif" becomes
http://host/some/path;123/images/brane.gif
... so we see the old, embarassing picture, instead of the new
replacement you've dropped in at HEAD.
> Since this
>is the case, I think appending the revision number to the end of the URL
>seems to be the most natural way. And as ';' appears to be an URI
>separator that has the right semantics (i.e., it indicates a different
>resource), the URL;REV syntax is sane. We could also support URL;{date}...
>
>
Sure, good idea. But you should just support it anywhere within the
URL, to make it possible to give the relative filename references the
right meaning.
It's easy to deal with a second version spec in the same URL: just
declare the URL invalid. 404.
Luke
The purpose of having the
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 6 12:18:43 2003
