[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Official revision syntax for Subversion URLs

From: Luke Blanshard <luke_at_blanshard.us>
Date: 2003-08-06 12:18:34 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.