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

Re: svn commit: r11509 - branches/1.1.x

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2004-10-20 19:23:44 CEST

Ben Reser wrote:

>On Wed, Oct 20, 2004 at 08:00:51AM -0500, lundblad@tigris.org wrote:
>>Author: lundblad
>>Date: Wed Oct 20 08:00:43 2004
>>New Revision: 11509
>> branches/1.1.x/STATUS
>>* STATUS: Veto r11490, but vote for r11501.
>>Modified: branches/1.1.x/STATUS
>>Url: http://svn.collab.net/viewcvs/svn/branches/1.1.x/STATUS?view=diff&rev=11509&p1=branches/1.1.x/STATUS&r1=11508&p2=branches/1.1.x/STATUS&r2=11509
>>--- branches/1.1.x/STATUS (original)
>>+++ branches/1.1.x/STATUS Wed Oct 20 08:00:43 2004
>>@@ -52,8 +52,11 @@
>> It used to work. It should work now.
>> Notes:
>> r11490 is just cleanups. But makes it merge cleanly.
>>+ OTOH, r11490 breaks file://localhost//machine/repos unnecessarily.
>What? You want a URL that points to a remote machine to accept a
>hostname of localhost? Your desired behavior of such a URL is bogus.
No it't not. The RFC is explicit in stating that URLs using the file:
schema can have two forms:


(that is, the host name part must be either empty or "localhost"). We've
supported both in the past, therefore we should support both now.

>Windows itself won't even accept that URL. It'll take the following
>URLS though:
And file://///machine/path.

>Personally I believe the only one we should support is the later.
The form file://machine/path violates the RFC if machine isn't "localhost".

>Anytime the hostname is blank or localhost we should interpret it as a
>local name and that means that duplicate path separators are no-ops.
>So I'd veto any implementation that supports
But they're closer to being valid URLS according to the RFC.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 19:24:17 2004

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.