On Sat, Mar 26, 2011 at 09:51:46AM -0400, Greg Stein wrote:
> > --- subversion/trunk/subversion/libsvn_wc/wc-queries.sql (original)
> > +++ subversion/trunk/subversion/libsvn_wc/wc-queries.sql Mon Mar 14
> 17:24:05 2011
> > @@ -910,6 +910,11 @@ WHERE wc_id = ?1 AND (local_relpath = ?2
> >pr
On Sat, Mar 26, 2011 at 09:46:48AM -0400, Greg Stein wrote:
> If it only needs to detect a single row, then LIMIT 1 should be in the
> query.
Is there really a significant difference between LIMIT 1 and not stepping
through more than one result row?
I'd rather keep the queries reusable for contex
On 28.03.2011 13:32, Stefan Sperling wrote:
> On Sat, Mar 26, 2011 at 09:46:48AM -0400, Greg Stein wrote:
>> If it only needs to detect a single row, then LIMIT 1 should be in the
>> query.
> Is there really a significant difference between LIMIT 1 and not stepping
> through more than one result ro
On Mar 28, 2011 7:32 AM, "Stefan Sperling" wrote:
>
> On Sat, Mar 26, 2011 at 09:46:48AM -0400, Greg Stein wrote:
> > If it only needs to detect a single row, then LIMIT 1 should be in the
> > query.
>
> Is there really a significant difference between LIMIT 1 and not stepping
> through more than
On Fri, Mar 25, 2011 at 08:38:55PM -, hwri...@apache.org wrote:
> Author: hwright
> Revision: 1081487
> Modified property: svn:log
>
> Modified: svn:log at Fri Mar 25 20:38:55 2011
> --
> --- svn:log (original)
> +++ s
On Mar 28, 2011 7:41 AM, "Greg Stein" wrote:
>
>
> On Mar 28, 2011 7:32 AM, "Stefan Sperling" wrote:
> >
> > On Sat, Mar 26, 2011 at 09:46:48AM -0400, Greg Stein wrote:
> > > If it only needs to detect a single row, then LIMIT 1 should be in the
> > > query.
> >
> > Is there really a significant
We have this pattern in several places within wc_db:
svn_sqlite__get_statement(&stmt, ...)
svn_sqlite_step(&have_row, stmt);
while (have_row)
{
if (cancel_func)
SVN_ERR(cancel_func(cancel_baton));
/* do stuff */
svn_sqlite_step(&have_row, stmt);
}
svn_
Stepping back... should cancellation even be in the API? When it was first
designed, I never imagined any function taking long enough to require a
cancel func. That would be left to callers, since each function would be
short/atomic/quick.
And what happens with the transaction here?
And is it rea
Greg Stein writes:
> I recognize we need to grow the scope of transactions for speed purposes,
> but let's do it in a way based on semantics rather than implementation. For
> example: to speed checkout, we could have an API to add a complete directory
> of nodes, rather than an API to start/end a
On 25 March 2011 at 19:19, Hyrum K Wright wrote
> On Fri, Mar 25, 2011 at 2:11 PM, C. Michael Pilato
> wrote:
>> On 03/25/2011 11:31 AM, Hyrum K Wright wrote:
>>> Neil,
>>> Thanks for the report. In attempting to reproduce, I wasn't even able
>>> to get as far as comparing the dumpfiles, as svnr
On Mar 28, 2011 8:23 AM, "Philip Martin" wrote:
>
> Greg Stein writes:
>
> > I recognize we need to grow the scope of transactions for speed
purposes,
> > but let's do it in a way based on semantics rather than implementation.
For
> > example: to speed checkout, we could have an API to add a comp
On Mon, Mar 28, 2011 at 07:49:22AM -0400, Greg Stein wrote:
> On Mar 28, 2011 7:41 AM, "Greg Stein" wrote:
> > Think about how the query optimizer/planner would work. Consider whether a
> result set needs to be constructed.
> >
> > ... a LIMIT 1 provides a ton of help to the SQL engine about what
On Mar 28, 2011 8:32 AM, "Stefan Sperling" wrote:
>
> On Mon, Mar 28, 2011 at 07:49:22AM -0400, Greg Stein wrote:
> > On Mar 28, 2011 7:41 AM, "Greg Stein" wrote:
> > > Think about how the query optimizer/planner would work. Consider
whether a
> > result set needs to be constructed.
> > >
> > > .
On 28.03.2011 14:13, Greg Stein wrote:
> Stepping back... should cancellation even be in the API? When it was first
> designed, I never imagined any function taking long enough to require a
> cancel func.
As an example, I can cite that recursive proplist that I turned upside
down some time ago. On
Actually, it did. Mike committed it in r1084335, and reported that
fact in this thread on Mar 22.
Best,
-Hyrum
On Sun, Mar 27, 2011 at 7:27 PM, Gavin Baumanis wrote:
> Ping.
> This patch submission has received no comments.
>
>
>
> On 22/03/2011, at 8:27 AM, Danny Trebbien wrote:
>
>> On Mon, M
r1086218. Thanks for the ping.
-Hyrum
On Sun, Mar 27, 2011 at 7:12 PM, Gavin Baumanis wrote:
> Ping. This patch submission has received no comments.
>
>
> On 28/02/2011, at 2:15 AM, Noorul Islam K M wrote:
>
>>
>> Attached patch removes unused import.
>>
>> Log
>> [[[
>>
>> * subversion/tests/c
> -Original Message-
> From: Branko Čibej [mailto:br...@xbc.nu] On Behalf Of Branko Cibej
> Sent: maandag 28 maart 2011 14:54
> To: dev@subversion.apache.org
> Subject: Re: resetting sqlite statements and cancellation
>
> On 28.03.2011 14:13, Greg Stein wrote:
> > Stepping back... should
On Mon, Mar 28, 2011 at 08:42:02AM -0400, Greg Stein wrote:
> On Mar 28, 2011 8:32 AM, "Stefan Sperling" wrote:
> >
> > On Mon, Mar 28, 2011 at 07:49:22AM -0400, Greg Stein wrote:
> > > On Mar 28, 2011 7:41 AM, "Greg Stein" wrote:
> > > > Think about how the query optimizer/planner would work. Co
On Mon, Mar 28, 2011 at 8:30 AM, Stefan Sperling wrote:
> On Mon, Mar 28, 2011 at 08:42:02AM -0400, Greg Stein wrote:
>> On Mar 28, 2011 8:32 AM, "Stefan Sperling" wrote:
>> >
>> > On Mon, Mar 28, 2011 at 07:49:22AM -0400, Greg Stein wrote:
>> > > On Mar 28, 2011 7:41 AM, "Greg Stein" wrote:
>>
Here is a patch that attempts to fix issue #3014.
In the issue, Julian suggests that there should be a policy as to when
svn should and should not report errors on broken pipes.
I think that would complicate things too much.
So this patch takes a much simpler approach (see log message).
Does anyo
> -Original Message-
> From: cmpil...@apache.org [mailto:cmpil...@apache.org]
> Sent: vrijdag 25 maart 2011 20:11
> To: comm...@subversion.apache.org
> Subject: svn commit: r1085523 -
> /subversion/trunk/subversion/tests/cmdline/svnrdump_tests.py
>
> Author: cmpilato
> Date: Fri Mar 25 1
On Mon, Mar 28, 2011 at 08:42:56AM -0500, Hyrum K Wright wrote:
> So the SELECT 1 determines what data gets return (which you don't care
> about), and the LIMIT 1 determines how much data gets returned (of
> which you only care about 0 or >0 rows, hence the LIMIT).
Thanks, that makes sense :) r10
Hi Mark,
I'm running Ubuntu 10.04 on an Intel Pentium 4 CPU 2.26GHz with 2GiB of RAM.
Here are the benchmark results for svn 1.6.6 (provided by canonical for
my OS) and svn trunk (r1086245).
Trunk is taking nearly twice as long as 1.6.6... Am I doing something
wrong... is it because of enabl
On Mon, Mar 28, 2011 at 11:28 AM, Arwin Arni wrote:
> I'm running Ubuntu 10.04 on an Intel Pentium 4 CPU 2.26GHz with 2GiB of RAM.
>
> Here are the benchmark results for svn 1.6.6 (provided by canonical for my
> OS) and svn trunk (r1086245).
>
> Trunk is taking nearly twice as long as 1.6.6... Am
On Fri, Mar 25, 2011 at 12:33 PM, Mark Phippard wrote:
> Hi,
>
> I have been working on a framework for writing tests to record
> performance. I have something good enough to share:
>
> https://ctf.open.collab.net/sf/projects/csvn
>
> It is pretty easy to add new tests if you have ideas on more t
On Mon, Mar 28, 2011 at 1:12 PM, Hyrum K Wright wrote:
> Very cool to see something which will hopefully give us some
> quantitative measure of performance.
>
> I've seen people submit reports based on particular revisions. Would
> it be possible to run the same suite of tools across a number of
Mark Phippard wrote on Mon, Mar 28, 2011 at 13:08:05 -0400:
> On Mon, Mar 28, 2011 at 11:28 AM, Arwin Arni wrote:
>
> > I'm running Ubuntu 10.04 on an Intel Pentium 4 CPU 2.26GHz with 2GiB of RAM.
> >
> > Here are the benchmark results for svn 1.6.6 (provided by canonical for my
> > OS) and svn t
I ran the benchmark test against an http 1.6 and 1.7 server. Details are here:
https://ctf.open.collab.net/sf/wiki/do/viewPage/projects.csvn/wiki/HTTPv2
The results are not encouraging.
* Compared to 1.6, checkout seems to be the biggest problem.
* HTTPv2 seems to help Neon more than it does S
Thanks Hyrum,
Appreciate the update.
I'll remove it from my "watch" list.
On 28/03/2011, at 11:58 PM, Hyrum K Wright wrote:
> Actually, it did. Mike committed it in r1084335, and reported that
> fact in this thread on Mar 22.
>
> Best,
> -Hyrum
>
> On Sun, Mar 27, 2011 at 7:27 PM, Gavin Baum
On 25/03/2011 17:33, Mark Phippard wrote:
> Hi,
>
> I have been working on a framework for writing tests to record
> performance. I have something good enough to share:
May I make an observation about these benchmarks...?
When I provided some benchmarks that included 'checkout' tests I was
spec
On Mon, Mar 28, 2011 at 5:42 PM, John Beranek wrote:
> On 25/03/2011 17:33, Mark Phippard wrote:
>> Hi,
>>
>> I have been working on a framework for writing tests to record
>> performance. I have something good enough to share:
>
> May I make an observation about these benchmarks...?
>
> When I p
Mark Phippard writes:
> There is one issue that I want to raise that I do not think is an
> outlier. I was expecting HTTPv2 to yield significant improvements,
> and so I stopped the Apache server after each test so I could grab its
> logs. I wanted to be able to show how much the HTTP traffic w
Hi Mark,
Here is another data point, for my old (t)rusty Windows XP (32-bit)
this time, on a system with a pretty slow hard disk (5.4k rpm), 1.83
GHz Intel T2400 cpu, 3 GB RAM.
I must say the results look very good for 1.7 (r1086021) compared to
1.6.16 on this system. Especially for the "Folder t
On Mon, Mar 28, 2011 at 18:14, Philip Martin wrote:
> Mark Phippard writes:
>
>> There is one issue that I want to raise that I do not think is an
>> outlier. I was expecting HTTPv2 to yield significant improvements,
>> and so I stopped the Apache server after each test so I could grab its
>> lo
On 28/03/2011 23:00, Mark Phippard wrote:
> On Mon, Mar 28, 2011 at 5:42 PM, John Beranek wrote:
>> On 25/03/2011 17:33, Mark Phippard wrote:
>>> Hi,
>>>
>>> I have been working on a framework for writing tests to record
>>> performance. I have something good enough to share:
>>
>> May I make an
On Mon, Mar 28, 2011 at 17:42, John Beranek wrote:
> On 25/03/2011 17:33, Mark Phippard wrote:
>> Hi,
>>
>> I have been working on a framework for writing tests to record
>> performance. I have something good enough to share:
>
> May I make an observation about these benchmarks...?
>
> When I pro
On 28/03/2011 23:45, Greg Stein wrote:
> On Mon, Mar 28, 2011 at 17:42, John Beranek wrote:
>> On 25/03/2011 17:33, Mark Phippard wrote:
>>> Hi,
>>>
>>> I have been working on a framework for writing tests to record
>>> performance. I have something good enough to share:
>>
>> May I make an obser
On Mon, Mar 28, 2011 at 18:51, John Beranek wrote:
> On 28/03/2011 23:45, Greg Stein wrote:
>> On Mon, Mar 28, 2011 at 17:42, John Beranek wrote:
>>> On 25/03/2011 17:33, Mark Phippard wrote:
Hi,
I have been working on a framework for writing tests to record
performance. I ha
Translation status report for trunk@r1086468
lang trans untrans fuzzy obs
--
de2049 135 255 217
es1986 198 285 355
fr2171 13 30 24
it1840 344 479 174
ja1978
'Daniel Shahaf' wrote on Mon, Mar 28, 2011 at 00:16:49 +0200:
> Bert Huijben wrote on Sun, Mar 27, 2011 at 19:26:50 +0200:
> > and there are easier (and more
> > performant) ways to check if a node is part of a working copy (e.g. helpers
> > to check if a path is switched/a wc root).
>
> Could yo
40 matches
Mail list logo