Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local

> [hidden email] 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.

Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local

Peter N. Lundblad wrote:

>On Fri, 22 Apr 2005, [UTF-8] Branko ?^Libej wrote:
>
>
>
>>[hidden email] 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.

Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local

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.

Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local

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. :)

> > 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:-)

Re: svn commit: r14404 - trunk/subversion/libsvn_ra_local

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.

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 ...