Branko Čibej wrote on Mon, 07 Jan 2019 05:55 +0100:
> On 06.01.2019 19:54, Daniel Shahaf wrote:
> > Branko Čibej wrote on Sun, 06 Jan 2019 19:37 +0100:
> >> A simple check would be:
> >>
> >> * if 0x0a is on an odd offset, and the next byte is 0x00, then it's a
> >> UTF-16-LE linefeed;
> >> * else if 0x0a is on an even offset, and the _previous_ byte is 0x00,
> >> then it's a UTF-16-BE linefeed;
> > Would would happen if it were an ASCII/UTF-8 file that happened to
> > have a literal NUL byte next to an LF byte? I have seen/used
> > some of those.
>
> Yes, well, in that case the NUL just might randomly "move" from one line
> to the next, depending on changes in the file. Nothing we can do
> short-term will fix that ... and as far as I'm concerned that's not a
> valid text file, so it won't disturb me too much if blame results are a
> bit fuzzy in such cases.
You don't actually give any reason why we shouldn't support text files
with embedded NULs.
> > (We even parse that in mod_dav_svn, I think?)
>
> Even if we do, it's irrelevant to this discussion. We set the value of
> the Content-Type header based on svn:mime-type for a simple GET request,
> but don't interpret it otherwise on the server side.
The relevance is that the property may be already set in users' repositories.
Received on 2019-01-07 06:18:07 CET