I intend to roll 1.7.17 and 1.8.9 sometime next week. Please take some time
over the next week to look at STATUS in the respective branches and vote for
issues.
Thanks.
Julian Foad writes:
> Hi Philip. Amidst the rest of the discussion perhaps you missed this:
>
> Julian Foad wrote:
>> Index: subversion/include/svn_fs.h
>> ===
>> * For each path in @a targets @a lock_callback will be invoked
>>
Hi Philip. Amidst the rest of the discussion perhaps you missed this:
Julian Foad wrote:
> Index: subversion/include/svn_fs.h
> ===
> * For each path in @a targets @a lock_callback will be invoked
> * passing @a lock_baton and the
Ivan Zhakov wrote:
> Julian Foad wrote:
>> It seems the main problem here is simply that this log message summary line
>> gives
>> a false impression about the magnitude of this particular change.
[...]
>> I totally support this particular kind of change. It's simply good interface
>> design.
>
On Sat, Apr 12, 2014 at 8:35 PM, Daniel Shahaf wrote:
> Stefan Fuhrmann wrote on Fri, Apr 11, 2014 at 22:01:53 +0200:
> > Now, if there were 50 requests for the *same* reconstructed data:
> >
> > file_t repo_files[50][20]
> > for k in 0..49 parallel_do
> > for i in 0..19 : repo_fil
On 13 April 2014 08:40, wrote:
> Author: stefan2
> Date: Sun Apr 13 04:40:40 2014
> New Revision: 1586922
>
> URL: http://svn.apache.org/r1586922
> Log:
> Speed up file / stream comparison, i.e. minimize the processing overhead
> for finding the first mismatch.
>
> The approach is two-sided. Ins
On 12 April 2014 00:01, Stefan Fuhrmann wrote:
> It seems that the document in notes/ did not make it clear what
> the actual problem is and how it applies to Subversion servers.
> Let me try to illustrate it.
>
[...]
>
> Should these trends be confirmed for "real" HW, networks and ra_serf,
> I'd
On 14 April 2014 12:23, Julian Foad wrote:
> Bert Huijben wrote:
>>> Author: stefan2
>>> URL: http://svn.apache.org/r1586947
>>> Log:
>>> Improve MT scalability of the FSFS DAG traversal code.
>
> It seems the main problem here is simply that this log message summary line
> gives a false impr
I'm happy to announce the release of Apache Subversion 1.9.0-alpha2.
Please choose the mirror closest to you by visiting:
http://subversion.apache.org/download/#pre-releases
The SHA1 checksums are:
c1de8633db4d8bc4b3145fec51b4079ca560f2a3 subversion-1.9.0-alpha2.tar.bz2
bfbe16a6820d7
On 14.04.2014 17:13, Bert Huijben wrote:
> But are you using 100% the same binaries on the server side and in the client?
>
> (As far as I know most binary providers deliver different binaries towards
> servers and clients)
>
>
>
> I don’t think we usually compile the client code with memcached
But are you using 100% the same binaries on the server side and in the client?
(As far as I know most binary providers deliver different binaries towards
servers and clients)
I don’t think we usually compile the client code with memcached support, and a
few other server side technologies.
On 14 Apr 2014 14:55, "Bert Huijben" wrote:
>
> But why do we use gettext on server processes side in the first place?
FSFS is far from being exclusively server-side. And there are better ways
for avoiding gettext than trying to guess whether your code is running in a
server process or not. Who's
Hi all,
This is nothing new (introduced way back when in 1.6),
but I have only become aware of it during my recent
scalability testing. I think I can fix that but that won't
happen until the end of next week or so.
Scenario: Large files have been cached and now a
number of clients request these f
Can you please improve your log message to tell what you actually did here.
You improved the code flow within some private parts of fsfs to avoid creating
errors.
What your log message tells to somebody that is reading the log message for
review:
I read the message as
* “HUGE
On Sun, Apr 13, 2014 at 5:28 PM, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: stef...@apache.org [mailto:stef...@apache.org]
> > Sent: zondag 13 april 2014 06:41
> > To: comm...@subversion.apache.org
> > Subject: svn commit: r1586922 - in /subversion/trunk/subversion:
> > incl
"Bert Huijben" writes:
> Unless there are a lot of string creations to create a vey specific
> error message, I've never seen a construction of svn_error_t * in any
> performance traces...
It is possible: in 2003 I comitted r847626 to avoid an svn_error_t
overhead in the working-copy access-bato
On Sun, Apr 13, 2014 at 6:18 PM, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: stef...@apache.org [mailto:stef...@apache.org]
> > Sent: zondag 13 april 2014 11:45
> > To: comm...@subversion.apache.org
> > Subject: svn commit: r1586947 - in
> > /subversion/trunk/subversion/libsv
Philip Martin writes:
> Julian Foad writes:
>
>> This commit changes the output format of paths from no leading slash
>> ('relpath' style) to having a leading slash ('fspath' style). This
>> seems to be against the desired path format for a dump file, although
>> the documentation in is not exp
Julian Foad writes:
> This commit changes the output format of paths from no leading slash
> ('relpath' style) to having a leading slash ('fspath' style). This
> seems to be against the desired path format for a dump file, although
> the documentation in is not explicit.
>
> I noticed this becau
Hi Philip,
This commit changes the output format of paths from no leading slash ('relpath'
style) to having a leading slash ('fspath' style). This seems to be against the
desired path format for a dump file, although the documentation in
is not explicit.
I noticed this because it crashes 'sv
Bert Huijben wrote:
>> Author: stefan2
>> URL: http://svn.apache.org/r1586947
>> Log:
>> Improve MT scalability of the FSFS DAG traversal code.
It seems the main problem here is simply that this log message summary line
gives a false impression about the magnitude of this particular change.
21 matches
Mail list logo
