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

Re: Summary: URL rev proposals

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-08-16 00:14:47 CEST

On Fri, Aug 15, 2003 at 09:18:01AM +0200, Julian Reschke wrote:
>...
> > We could choose it at random at apache start time. No spite involved,
> > just aggressive quality assurance.

ROFL

> That would be a severe RFC3253 conformance bug. Once a DeltaV client has
> obtained a version URI (for instance using REPORT or by checking the
> Location header upon CHECKIN), it MUST NOT ever change, so that the client
> can keep the reference to the version.

Incorrect. The resource identified by that URL should never change. But the
URL itself can change.

As I recall, the "mutable" version resource idea that was floating around
DeltaV for a while would actually delete old version resources and introduce
new ones. Thus, it was quite possible to have a URL that would (eventually)
return a 404.

> This basically means that even a Subversion update is not allowed to ever
> change that format (nor an administrator).

That's bunk. The URL can always change. Just not the contents. And note that
if you get a 404, then you can just look it up again. In fact, the
Subversion client does *exactly* that. When it tries for a version resource
(at a cached URL), gets a 404, then it goes back through the motions to
rediscover the "proper" URL for that version resource.

The web is a flexible space. Simply changing a host name, or the root of a
repository is going to cause changes in URLs. And I believe that is okay.

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 Sat Aug 16 00:06:37 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.