On 04.01.2019 16:22, Branko Čibej wrote:
> The following just started appearing on the macos build slave, and
> similar errors are being emitted on the Windows bots:
>
> (see https://ci.apache.org/builders/svn-x64-macosx-full/builds/2275)
It turns out this was caused by r1850344, which introduced
On 07.01.2019 06:17, Daniel Shahaf wrote:
> 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, th
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;
> >>
On 06.01.2019 20:10, Stefan Kueng wrote:
>
>
> On 06.01.2019 19:37, Branko Čibej wrote:
>
>> Windows default is UTF-16-LE, at least on x86(_64) and other
>> little-endian architectures. I'm not sure what they do on ARM but I'd be
>> surprised if Windows doesn't put it in little-endian mode, given t
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 0
Stefan Kueng wrote on Sun, Jan 06, 2019 at 20:40:28 +0100:
> +++ subversion/include/svn_client.h (working copy)
> @@ -736,10 +736,11 @@
> * @{
> */
>
> -/** Callback type used by svn_client_blame5() to notify the caller
> +/** Callback type used by svn_client_blame6() to notify the caller
>
On 06.01.2019 19:54, Daniel Shahaf wrote:
The encoding may also be set explicitly via a svn:mime-type="text/foo;
charset=utf-16-le" property. (We even parse that in mod_dav_svn, I think?)
Setting the mime-type to text/.. with the utf16 charset helps only that
the --force flag doesn't need t
On 06.01.2019 19:37, Branko Čibej wrote:
Windows default is UTF-16-LE, at least on x86(_64) and other
little-endian architectures. I'm not sure what they do on ARM but I'd be
surprised if Windows doesn't put it in little-endian mode, given that
decades of legacy software assume little-endian.
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;
Woul
On 06.01.2019 17:16, Stefan Kueng wrote:
>
>
> On 06.01.2019 15:05, Branko Čibej wrote:
>
>> Sorry about getting into this late, but as Julian said:
>>
>>> * we already have a (char*, len) wrapper, called svn_string_t, so I
>>> would expect it would be neatest to use that;
>>
>> but the patch has:
On 06.01.2019 15:05, Branko Čibej wrote:
Sorry about getting into this late, but as Julian said:
* we already have a (char*, len) wrapper, called svn_string_t, so I would
expect it would be neatest to use that;
but the patch has:
@@ -758,6 +758,28 @@
·*·will·be·true·if·the·reason·there·
On 06.01.2019 15:22, Julian Foad wrote:
Branko Čibej wrote:
+ const svn_string_t line = {sb->data, sb->len};
In plain old C, we can't write that, but we have a helper function:
svn_stringbuf__morph_into_string().
but that destroys the original stringbuf, but that one is sti
troycurti...@apache.org wrote on Sun, Jan 06, 2019 at 00:42:27 -:
> Author: troycurtisjr
> Date: Sun Jan 6 00:42:27 2019
> New Revision: 1850519
>
> URL: http://svn.apache.org/viewvc?rev=1850519&view=rev
> Log:
> On branch swig-py3: Improve error messages for swig language builds.
>
> * Make
On 06.01.2019 15:22, Julian Foad wrote:
> Branko Čibej wrote:
>> + const svn_string_t line = {sb->data, sb->len};
> In plain old C, we can't write that, but we have a helper function:
> svn_stringbuf__morph_into_string().
I've noticed that clang is a bit deficient when it comes to pe
Branko Čibej wrote:
> + const svn_string_t line = {sb->data, sb->len};
In plain old C, we can't write that, but we have a helper function:
svn_stringbuf__morph_into_string().
--
- Julian
On 06.01.2019 15:05, Branko Čibej wrote:
> Until we have better support for other Unicode representations, we
> should detect that null byte and include it as part of the reported
> blame line.
That might also imply detecting that the file encoding is not UTF-16-BE
instead ... which could very lik
On 06.01.2019 14:10, Stefan Kueng wrote:
>
>
> On 05.01.2019 22:35, Daniel Shahaf wrote:
>> Stefan Kueng wrote on Sat, 05 Jan 2019 21:15 +0100:
>>> here's a patch using svn_stringbuf_t for review.
>>
>> Change "Provided for backwards compatibility with the 1.6 API" to
>> "Provided for backwards com
On 05.01.2019 22:35, Daniel Shahaf wrote:
Stefan Kueng wrote on Sat, 05 Jan 2019 21:15 +0100:
here's a patch using svn_stringbuf_t for review.
Change "Provided for backwards compatibility with the 1.6 API" to
"Provided for backwards compatibility with the 1.11 API" in
svn_client_blame5()'s d
18 matches
Mail list logo
