> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: Saturday, August 16, 2003 3:15 AM
> To: Greg Stein
> Cc: dev@subversion.tigris.org
> Subject: Re: Summary: URL rev proposals
>
>
> My reading of RFC 3253 supports Greg's position, much as I would like
> Julian's position to be right. But I think there's another argument to
> be made from a quality of implementation standpoint.
>
> On Fri, 2003-08-15 at 18:14, Greg Stein wrote:
> > 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.
>
> It's true. But a web server which provides stable, long-lived URLs is
> superior to one which does not. I see nothing in RFC 3253 which
> suggests that version resource URLs should be considered internal or
> unstable, so we should endeavor to make them stable and long-lived.
> This means no more talk of changing the version resource URLs "out of
> spite."
Agreed. Greg Stein of course is right that it's RFC3253-compliant to change
the version URI namespace as long as the same URL never ever identifies a
different version. That's what RFC3253 absolutely requires. In particular,
versions may get deleted. That means that the URL may get unmapped again,
but it will *still* identify the same version (it's just that the server
won't have any representations for that version anymore).
Gred Hudson is correct in that one of the most important use cases for
stable version URIs is to enable clients to bookmark them. Therefore it's
IMHO nonsensical to suggest that version URIs are going to change as a
result of standard code maintenance or site administration. If this occurs,
someone is doing a bad job.
Just my 2 cents,
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 16 08:48:46 2003