On Mon, Apr 11, 2011 at 9:41 PM, Greg Stein wrote:
> Woah. When did svn_sqlite__prepare arrive?
$ svnd blame subversion/libsvn_subr/sqlite.c | grep svn_sqlite__prepare
875453hwright
SVN_ERR(svn_sqlite__prepare(&db->prepared_stmts[stmt_idx], db,
873188 gstein svn_sqlite__prepare(svn_sqlite
The function has existed for a long time, but remained unused, AFAIK. I
don't think it should be, and it should be swutched to file-private.
On Apr 11, 2011 10:41 PM, "Greg Stein" wrote:
> Woah. When did svn_sqlite__prepare arrive?
>
> I'm basically -1 on that.
>
> The whole idea behind static sta
Woah. When did svn_sqlite__prepare arrive?
I'm basically -1 on that.
The whole idea behind static statements was to avoid SQL injection attacks.
Allowing the *code* to construct statements opens us up.
This is Not Good.
On Apr 11, 2011 8:31 PM, wrote:
> Author: hwright
> Date: Tue Apr 12 00:31:
I originally reported this issue with TortoiseSVN [1], but we narrowed it
down to an issue in Subversion 1.7dev.
If I am committing a working copy with modifications to dir1 and dir2, dir2
being an svn:externals directory that points to a location *within* the
repository, I get an error that I di
Hi there,
Here is my contribution to the performance awareness movement (PAM)
recently forming on this list. The attached script (bigdir.txt) will
* create a repository and start svnserve on it
(to tell client and repository access performance apart)
* create folders with 1, 2, 4, 8, ... very
On 11.04.2011 12:15, Philip Martin wrote:
Mark Phippard writes:
Was reading the release notes on the new in-memory cache. How does
this work (provide benefits) with mod_dav_svn? It seems like the
cache is per-process. Aren't the processes (pre-fork MPM) with DAV
generally short-lived? If I
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: maandag 11 april 2011 19:09
> To: 'Philip Martin'; 'C. Michael Pilato'
> Cc: dev@subversion.apache.org
> Subject: RE: svn commit: r1089856 -
> /subversion/trunk/subversion/tests/cmdline/switch_tests.py
>
>
>
> >
On 04/11/2011 01:04 PM, Bob Archer wrote:
> I would even ask... why allow switched children? Is this really a heavily
> used feature of svn... or is it just a byproduct of the current WC
> implementation that a small percentage of users are taking advantage. I
> know people having switch children w
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: maandag 11 april 2011 18:15
> To: C. Michael Pilato
> Cc: dev@subversion.apache.org
> Subject: Re: svn commit: r1089856 -
> /subversion/trunk/subversion/tests/cmdline/switch_tests.py
>
> "C. Michael Pi
> "C. Michael Pilato" writes:
>
> > On 04/11/2011 05:53 AM, Philip Martin wrote:
> >> "C. Michael Pilato" writes:
> >>
> >>> But we obviously have precedent for supporting committed copies
> >>> of deeply switched things, so perhaps this isn't the best use
> of our time
> >>> right now.
> >>
> >
"C. Michael Pilato" writes:
> On 04/11/2011 05:53 AM, Philip Martin wrote:
>> "C. Michael Pilato" writes:
>>
>>> But we obviously have precedent for supporting committed copies
>>> of deeply switched things, so perhaps this isn't the best use of our time
>>> right now.
>>
>> "Support" is gener
On Mon, Apr 11, 2011 at 8:49 AM, Mark Phippard wrote:
> Just an fyi ...
>
> I am not sure what has caused it as all I have seen is a number of
> commits from Bert that said they were eliminating SQLite queries, but
> the performance test results have been showing the times for checkout
> and updat
On 04/07/2011 08:49 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400:
>> "Remove temp APIs": I would put this at "nice to have". These APIs are
>> private, so what's the penalty if they wind up in the release?
>
> We'd have to support them privately for t
On 04/09/2011 07:29 AM, Stefan Fuhrmann wrote:
> On 07.04.2011 17:19, C. Michael Pilato wrote:
>> "Review of performance branch": I get the sense from the list traffic that
>> we've kinda pulled what we want from this branch into trunk for now. Can
>> someone confirm?
>
> Someone can and I do ;)
On 04/11/2011 05:53 AM, Philip Martin wrote:
> "C. Michael Pilato" writes:
>
>> But we obviously have precedent for supporting committed copies
>> of deeply switched things, so perhaps this isn't the best use of our time
>> right now.
>
> "Support" is generous, we only really support copied swit
On Mon, Apr 11, 2011 at 6:01 AM, Neels Hofmeyr wrote:
> This morning's svn speed ratings...
> Far less numbers this time.
>
> Can anyone recommend a python charting thing? I've seen a couple, but if
> anyone has already cycled through them, I'd appreciate a hint or to.
> Might try py-svg aka svg.c
Just an fyi ...
I am not sure what has caused it as all I have seen is a number of
commits from Bert that said they were eliminating SQLite queries, but
the performance test results have been showing the times for checkout
and update to be getting slower. For example on the relatively
lightweight
~Neels
/home/neels/svnbench/20110411-002419
Started at Mon Apr 11 00:24:19 UTC 2011
-
Results for dir levels: 5 spread: 5
Timings for 5x5_1.6
N min max avgoperation (unit is seconds)
6 333.93 391.58 35
Mark Phippard writes:
> Was reading the release notes on the new in-memory cache. How does
> this work (provide benefits) with mod_dav_svn? It seems like the
> cache is per-process. Aren't the processes (pre-fork MPM) with DAV
> generally short-lived? If I checkout trunk and someone else
> im
On Apr 10, 2011 3:26 PM, "Bert Huijben" wrote:
>
>
>
> > -Original Message-
> > From: Greg Stein [mailto:gst...@gmail.com]
> > Sent: zondag 10 april 2011 7:26
> > To: dev@subversion.apache.org
> > Subject: Re: svn commit: r1090715 -
> > /subversion/trunk/subversion/libsvn_client/commit_uti
"C. Michael Pilato" writes:
> But we obviously have precedent for supporting committed copies
> of deeply switched things, so perhaps this isn't the best use of our time
> right now.
"Support" is generous, we only really support copied switches with no
modifications:
svnadmin create repo
svn im
"C. Michael Pilato" writes:
> "Remove obliterate code": I think the obliterate code is all tucked away in
> private functions and such at this point. Is that as far as we plan to take
> this in 1.7? If not, the purge of this stuff would be some pretty
> low-hanging fruit for a would-be contrib
22 matches
Mail list logo
