You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2005/04/22 16:06:45 UTC
Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local
lundblad@tigris.org wrote:
>Author: lundblad
>Date: Fri Apr 22 07:31:44 2005
>New Revision: 14404
>
>Modified:
> trunk/subversion/libsvn_ra_local/split_url.c
>
>Log:
>Comment addition.
>
>* subversion/libsvn_ra_local/split_url.c (svn_ra_local__split_URL):
> Add comment about the file:///\machine/share hack on Windows and the need
> to preserve support for it.
>
>
Eek, I missed most of this discussion before.
I vote for fixing this bug, not preserving it indefinitely. Our
compatibility rules don't say that we have to maintain bugs that people
happen to be relying on, because they didn't read the documentation.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local
Posted by Simon Large <sl...@slarge.plus.com>.
Peter N. Lundblad wrote:
>>> Note that according to Simon Large, the TSVN people were
>>> "recommended" to use this workaround in 1.1. I don't know where
>>> that mail is though.
>>>
>>>
>> I don't remember seeing anything like that, either.
>>
> http://svn.haxx.se/dev/archive-2005-04/1350.shtml
>
> Maybe Simon can elaborate.
Sorry folks. It was on the users list, not dev as I thought I
remembered, and the recommendation came from other users, not the
principal developers.
The original thread starts here:
http://svn.haxx.se/users/archive-2004-09/1645.shtml
and the file:///\server/path syntax recommendation appears here:
http://svn.haxx.se/users/archive-2004-09/1725.shtml
When Maxb pointed out that this was an accidental feature, my concern
was that it might disappear again and leave some users without UNC repo
access. Now that we have an official and much cleaner way of achieving
the same thing in 1.2 via file://server/path I am not so concerned. If
the ugly method disappears, it is easy to fix broken WCs with a
relocate.
I have updated TSVN docs to show the 1.2 access method, and also shown
the older unofficial method as deprecated - still works but not
recommended. If you want to remove it completely, then I can just make
the doc wording a bit stronger. Anyone who runs into problems will hit
the mailing list soon enough ...
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 25 Apr 2005, [UTF-8] Branko �^Libej wrote:
> Peter N. Lundblad wrote:
>
> >On Mon, 25 Apr 2005, [UTF-8] Branko �^Libej wrote:
> >
> >
> >>
> >
> >Where did we say not to use FSFS repositories over ra_local on a network
> >share?
> >
> Ah, you're right, I completely forgot about FSFS...
>
Yeah, that small and seldom used feature is easy to forget about:-)
> > Note that according to Simon Large, the TSVN people were
> >"recommended" to use this workaround in 1.1. I don't know where that mail
> >is though.
> >
> >
> I don't remember seeing anything like that, either.
>
http://svn.haxx.se/dev/archive-2005-04/1350.shtml
Maybe Simon can elaborate.
> >>particular reasons to keep supporting a bug that happened to be "used"
> >>by people who don't believe our documentation.
> >>
> >>
> >
> >But you seem to see a reason not to answer my first question. Exactly
> >what's the bug you want fixed?
> >
> >
> We shouldn't accept file:///\.... That we do is a bug that should be fixed.
>
OK, soyou want to special-case that in ra_local. I'm not sure it is worth
the effort. We can't just forbid \, or convert them to /, since it is
valid in pathnames. We can ensure that what follows the schem:// doesn't
start with /\ or \/. Isn't a documentation update enough? I, at least,
will put it below the priority of strlen and skip_uri_scheme, which means
someone else will have to do it:-)
> >We could introduce code to detect this hack on Windows, but I don't see a
> >reason to annoy people just for the sake of it.
> >
> >
> Oh, but it's so much fun seeing their faces afterwards. :)
>
Ah, I might raise the priority if you promise to transcribe these faces
into words, so I can laugh as well:-)
Best,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
>On Mon, 25 Apr 2005, [UTF-8] Branko �^Libej wrote:
>
>
>
>>Peter N. Lundblad wrote:
>>
>>
>>
>>>On Fri, 22 Apr 2005, [UTF-8] Branko �^Libej wrote:
>>>
>>>
>>>
>>>
>>>
>>>>I vote for fixing this bug, not preserving it indefinitely. Our
>>>>compatibility rules don't say that we have to maintain bugs that people
>>>>happen to be relying on, because they didn't read the documentation.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>What exactly do you want to be fixed? We currently support
>>>file://machine/share syntax, and happen to support file:///\machine/share.
>>>file:////machine/share isn't supported since one slash is dropped by our
>>>canonicalization routine.
>>>
>>>The problem with removing support for file:///\achine/share is that it was
>>>the only way to use ra_local on a network share in 1.1. So we will break
>>>peoples workng copies. Even if they can just switch --relocate, they will
>>>be annoyed by this.
>>>
>>>
>>>
>>>
>>We did not document file:///\... as being supported in 1.1, and we did
>>say not to use ra_local on network mounted filesystems. I see no
>>
>>
>
>Where did we say not to use FSFS repositories over ra_local on a network
>share?
>
Ah, you're right, I completely forgot about FSFS...
> Note that according to Simon Large, the TSVN people were
>"recommended" to use this workaround in 1.1. I don't know where that mail
>is though.
>
>
I don't remember seeing anything like that, either.
>>particular reasons to keep supporting a bug that happened to be "used"
>>by people who don't believe our documentation.
>>
>>
>
>But you seem to see a reason not to answer my first question. Exactly
>what's the bug you want fixed?
>
>
We shouldn't accept file:///\.... That we do is a bug that should be fixed.
>We could introduce code to detect this hack on Windows, but I don't see a
>reason to annoy people just for the sake of it.
>
>
Oh, but it's so much fun seeing their faces afterwards. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 25 Apr 2005, [UTF-8] Branko �^Libej wrote:
> Peter N. Lundblad wrote:
>
> >On Fri, 22 Apr 2005, [UTF-8] Branko �^Libej wrote:
> >
> >
> >
> >>I vote for fixing this bug, not preserving it indefinitely. Our
> >>compatibility rules don't say that we have to maintain bugs that people
> >>happen to be relying on, because they didn't read the documentation.
> >>
> >>
> >>
> >What exactly do you want to be fixed? We currently support
> >file://machine/share syntax, and happen to support file:///\machine/share.
> >file:////machine/share isn't supported since one slash is dropped by our
> >canonicalization routine.
> >
> >The problem with removing support for file:///\achine/share is that it was
> >the only way to use ra_local on a network share in 1.1. So we will break
> >peoples workng copies. Even if they can just switch --relocate, they will
> >be annoyed by this.
> >
> >
> We did not document file:///\... as being supported in 1.1, and we did
> say not to use ra_local on network mounted filesystems. I see no
Where did we say not to use FSFS repositories over ra_local on a network
share? Note that according to Simon Large, the TSVN people were
"recommended" to use this workaround in 1.1. I don't know where that mail
is though.
> particular reasons to keep supporting a bug that happened to be "used"
> by people who don't believe our documentation.
But you seem to see a reason not to answer my first question. Exactly
what's the bug you want fixed?
We could introduce code to detect this hack on Windows, but I don't see a
reason to annoy people just for the sake of it.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
>On Fri, 22 Apr 2005, [UTF-8] Branko �^Libej wrote:
>
>
>
>>lundblad@tigris.org wrote:
>>
>>
>>
>>>Log:
>>>Comment addition.
>>>
>>>* subversion/libsvn_ra_local/split_url.c (svn_ra_local__split_URL):
>>> Add comment about the file:///\machine/share hack on Windows and the need
>>> to preserve support for it.
>>>
>>>
>>>
>>>
>>Eek, I missed most of this discussion before.
>>
>>I vote for fixing this bug, not preserving it indefinitely. Our
>>compatibility rules don't say that we have to maintain bugs that people
>>happen to be relying on, because they didn't read the documentation.
>>
>>
>>
>What exactly do you want to be fixed? We currently support
>file://machine/share syntax, and happen to support file:///\machine/share.
>file:////machine/share isn't supported since one slash is dropped by our
>canonicalization routine.
>
>The problem with removing support for file:///\achine/share is that it was
>the only way to use ra_local on a network share in 1.1. So we will break
>peoples workng copies. Even if they can just switch --relocate, they will
>be annoyed by this.
>
>
We did not document file:///\... as being supported in 1.1, and we did
say not to use ra_local on network mounted filesystems. I see no
particular reasons to keep supporting a bug that happened to be "used"
by people who don't believe our documentation.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 22 Apr 2005, [UTF-8] Branko �^Libej wrote:
> lundblad@tigris.org wrote:
>
> >Log:
> >Comment addition.
> >
> >* subversion/libsvn_ra_local/split_url.c (svn_ra_local__split_URL):
> > Add comment about the file:///\machine/share hack on Windows and the need
> > to preserve support for it.
> >
> >
> Eek, I missed most of this discussion before.
>
> I vote for fixing this bug, not preserving it indefinitely. Our
> compatibility rules don't say that we have to maintain bugs that people
> happen to be relying on, because they didn't read the documentation.
>
What exactly do you want to be fixed? We currently support
file://machine/share syntax, and happen to support file:///\machine/share.
file:////machine/share isn't supported since one slash is dropped by our
canonicalization routine.
The problem with removing support for file:///\achine/share is that it was
the only way to use ra_local on a network share in 1.1. So we will break
peoples workng copies. Even if they can just switch --relocate, they will
be annoyed by this.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local
Posted by Max Bowsher <ma...@ukf.net>.
Branko Čibej wrote:
> lundblad@tigris.org wrote:
>
>> Author: lundblad
>> Date: Fri Apr 22 07:31:44 2005
>> New Revision: 14404
>>
>> Modified:
>> trunk/subversion/libsvn_ra_local/split_url.c
>>
>> Log:
>> Comment addition.
>>
>> * subversion/libsvn_ra_local/split_url.c (svn_ra_local__split_URL):
>> Add comment about the file:///\machine/share hack on Windows and the
>> need
>> to preserve support for it.
>>
>>
> Eek, I missed most of this discussion before.
>
> I vote for fixing this bug, not preserving it indefinitely. Our
> compatibility rules don't say that we have to maintain bugs that people
> happen to be relying on, because they didn't read the documentation.
Makes sense.
file://///server/share/path seems appropriate - Mozilla accepts it, it was
mentioned that TSVN already accepts it, and it is the most logical thing to
for someone translating their knowledge of file:///C:/path URLs to UNC
URLs - comparing paths and URLs:
file:/// C:\path
file:/// C:/path
file:/// \\server\share\path
file:/// //server/share/path
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org