Translation status report for trunk@r1667172
lang trans untrans fuzzy obs
--
de2923 2 2 504 +~o
es2281 644 853 530 ++U~~~
fr2587 338
On 16.03.2015 17:54, Bert Huijben wrote:
A fix for this generic problem has been applied to trunk in r1664938 (further
tweaks/extensions in 1664939,1664940,1664978,1664984).
Great -- this is exactly what I was looking for.
This introduces some behavior changes (such as the one you noted), so
"Bert Huijben" writes:
> Nice idea on the concept, but this patch doesn't implement that behavior
>
> You will see the first result very fast. (No behavior change)
I don't understand, I see a behaviour change when I try it.
The first few writes with my patch:
[pid 8814] writev(17, [{"HTTP/1.1
On Thu, Mar 5, 2015 at 3:11 PM, Stefan Fuhrmann <
stefan.fuhrm...@wandisco.com> wrote:
> On Sat, Jun 21, 2014 at 8:23 PM, Branko Čibej wrote:
>
>> I've started a page on the Wiki for the pre-release API review. I guess
>> I'm jumping the gun just a bit, but a couple days ago I noticed some
>> mi
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: maandag 16 maart 2015 18:10
> To: Julian Foad
> Cc: Bert Huijben; Marc Strapetz; dev
> Subject: Re: 1.9.x JavaHL: long initial delay when performing a log
>
> Julian Foad writes:
>
> > Flushing after
On Wed, Mar 11, 2015 at 6:04 PM, Julian Foad
wrote:
> Hi Stefan.
>
> A few comments below...
>
Thanks for the review, Julian! Uncovered a bug and
fixed all the things you found:
> - Original Message -
> > URL: http://svn.apache.org/r1665894
>
[...]
> > Modified: subversion/trunk/subve
Philip Martin wrote:
> Philip Martin writes:
>> Julian Foad writes:
>>> Flushing after the 1st, 2nd, 4th, 8th, ... log entry provides a crude
>>> approximation to the desired semantics which is more like "don't delay
>>> the first result more than a small fraction of a second, and don't
>>> delay t
Philip Martin writes:
> Julian Foad writes:
>
>> Flushing after the 1st, 2nd, 4th, 8th, ... log entry provides a crude
>> approximation to the desired semantics which is more like "don't delay
>> the first result more than a small fraction of a second, and don't
>> delay the next few results muc
Julian Foad writes:
> Flushing after the 1st, 2nd, 4th, 8th, ... log entry provides a crude
> approximation to the desired semantics which is more like "don't delay
> the first result more than a small fraction of a second, and don't
> delay the next few results much more than that either". In ot
> -Original Message-
> From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
> Sent: maandag 16 maart 2015 17:30
> To: dev@subversion.apache.org
> Subject: JavaHL: Exceptions in LogMessageCallback.singleMessage should abort
> the log immediately
>
> If e.g. a RuntimeException is thrown
If e.g. a RuntimeException is thrown in
LogMessageCallback#singleMessage, it's not processed in
LogMessageCallback::singleMessage and the log is continued nevertheless:
(1) At line 77 in LogMessageCallback.cpp, there should be returned an
appropriate error code.
(2) After line 122, JNIUtil::
Branko Čibej wrote:
> I'd like to suggest a slightly different flushing policy:
>
> --- log.c(revision 1667032)
> +++ log.c(working copy)
> @@ -68,6 +68,7 @@ struct log_receiver_baton
>/* Helper variables to force early bucket brigade flushes */
>int result_count;
> + int forced_fl
I voiced some concerns on IRC (
http://colabti.org/irclogger/irclogger_log/svn-dev?date=2015-03-16#l80
) about the patch http://svn.apache.org/r1666965 nominated for
backport to 1.9.x. More details below.
Bert Huijben wrote:
> Julian Foad wrote:
>> Marc Strapetz wrote:
>>> On 16.03.2015 01:50, Ber
On 16.03.2015 12:30, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Mon Mar 16 11:30:04 2015
> New Revision: 1666965
>
> URL: http://svn.apache.org/r1666965
> Log:
> Reduce the perceived very slow operation of svn log URL via mod_dav on
> large result sets that return not that much data, by
On Mon, Mar 16, 2015 at 03:46:32PM +0100, Marc Strapetz wrote:
> Since SmartSVN has been switched from SVNKit to JavaHL (in version 8.5), we
> have a quite large amount of users complaining about problems with special
> characters in file names on Mac OSX.
>
> This is in particular a problem for S
Since SmartSVN has been switched from SVNKit to JavaHL (in version 8.5),
we have a quite large amount of users complaining about problems with
special characters in file names on Mac OSX.
This is in particular a problem for SmartSVN, because SVNKit was
automatically converting to composed form
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: maandag 16 maart 2015 14:32
> To: Marc Strapetz
> Cc: Bert Huijben; dev
> Subject: Re: 1.9.x JavaHL: long initial delay when performing a log
>
> On 16 March 2015 at 11:00, Marc Strapetz
> wrote:
> > On
On 16 March 2015 at 11:00, Marc Strapetz wrote:
> On 16.03.2015 01:50, Bert Huijben wrote:
>> Our server reports use an apr feature that buffers +- 8 KByte data before
>> sending out the first data.
>>
>> In this specific JavaHL case you ask for just the revision numbers.
>> (Unlike the C api, Jav
On Tue, Mar 10, 2015 at 1:18 PM, Julian Foad
wrote:
> Ivan Zhakov wrote:
> >> URL: http://svn.apache.org/r1665437
> >> Modified: subversion/trunk/subversion/include/svn_fs.h
> >> - * @note Using FS ID based functions is now discouraged and may be
> fully
> >> - * deprecated in future releases. N
On 16.03.2015 01:50, Bert Huijben wrote:
-Original Message-
From: Marc Strapetz [mailto:marc.strap...@syntevo.com]
Once the log responds, a bunch of revisions are reported, so it seems
that there is some kind of caching of log records.
I've tested with latest 1.9.x sources on Windows but
20 matches
Mail list logo
