Hello,
On 15/04/13 23:14, Bo Chen wrote:
> SVN uses zlib to compress the new data in delta. By default, the
> compression level in the current implementation is 5, right? I am
> wondering what are differences by choosing different compression
> level? Is is a trade-off between compression rate and
15 apr 2013 kl. 14.45 skrev Philip Martin:
Avoid a "condition always true" warning on platforms where char
is unsigned by default, such as PowerPC and ARM.
Looks correct, +1
Thanks - committed as r1468255.
SVN uses zlib to compress the new data in delta. By default, the
compression level in the current implementation is 5, right? I am wondering
what are differences by choosing different compression level? Is is a
trade-off between compression rate and computational overhead?
Thanks.
Bo
danie...@apache.org wrote on Mon, Apr 15, 2013 at 17:48:50 -:
> Author: danielsh
> Date: Mon Apr 15 17:48:49 2013
> New Revision: 1468166
>
> URL: http://svn.apache.org/r1468166
> Log:
> backport.pl: use automatic merge when $SVN ≥ 1.8.0.
>
Clarification: this adds the code to use automatic
On Mon, Apr 15, 2013 at 1:32 PM, Daniel Shahaf wrote:
> Should svn-role (the STATUS mergebot) use a 1.8 build for running 'merge'?
Most definitely yes IMO. If we aren't prepared to use 1.8-dev for
this, then we probably branched too soon (not that I think we did).
> IIRC we discussed this befor
Should svn-role (the STATUS mergebot) use a 1.8 build for running 'merge'?
IIRC we discussed this before and decided we should use a 1.8 build as
soon as a 1.8.0 prerelease is available, so that's what I'll default to
doing.
On Mon, Apr 15, 2013 at 9:11 AM, Philip Martin
wrote:
> That's just repeating what Mattias said. What I want to clarify is why
> we want to use a double printf rather than having a new string.
The existing translation key doesn't have a newline on it. Most of
the uses it is inappropriate to jus
Ben Reser writes:
> On Mon, Apr 15, 2013 at 6:38 AM, Philip Martin
> wrote:
>> Mattias Engdegård writes:
>>
>>> Here is a patch. (I didn't add a newline to the string directly since
>>> it occurs in many places.)
>>
>> The explaination should go in the code not the email otherwise somebody
>> e
On Mon, Apr 15, 2013 at 6:38 AM, Philip Martin
wrote:
> Mattias Engdegård writes:
>
>> Here is a patch. (I didn't add a newline to the string directly since
>> it occurs in many places.)
>
> The explaination should go in the code not the email otherwise somebody
> else may change the code. I don
Mattias Engdegård wrote:
> If a file has both text and property conflicts, only resolving one of them
> leads
> to an incorrect conflict summary message.
I'll take this one. There's a bunch of stuff to sort out, here; marking both
conflicts as resolved at the same time is only one of the bugs
Mattias Engdegård writes:
> Here is a patch. (I didn't add a newline to the string directly since
> it occurs in many places.)
The explaination should go in the code not the email otherwise somebody
else may change the code. I don't understand the explaination, is this
to make translation easie
Mattias Engdegård writes:
> Avoid a "condition always true" warning on platforms where char
> is unsigned by default, such as PowerPC and ARM.
>
> * subversion/libsvn_subr/utf_validate.c
> (first_non_fsm_start_char, first_non_fsm_start_char_cstring):
>Add explicit cast to avoid warning when
On 14 April 2013 02:46, Ben Reser wrote:
> Unfortunately, it does not work with Visual Studio 2012 Windows
> Desktop Express due to the lack of devenv.(com|exe). However, the
> script is written to produce a the binaries in a way that they can be
> packaged. There's still some work to do here in
13 matches
Mail list logo
