On Fri, Sep 2, 2011 at 18:32, Peter Samuelson wrote:
>
> [Greg Stein]
>> Since we are selecting only "current nodes" for each local_relpath,
>> then I presume we don't need the apr_hash_get() in there, correct?
>
> Yeah, I confirmed with him on IRC that the wc_db.c change (chiefly
> deleting the e
[Greg Stein]
> Since we are selecting only "current nodes" for each local_relpath,
> then I presume we don't need the apr_hash_get() in there, correct?
Yeah, I confirmed with him on IRC that the wc_db.c change (chiefly
deleting the extraneous apr_hash_get() call) is a cleanup that could be
applie
Added issue #4005 (got some response on IRC).
~Neels
On 09/01/2011 11:34 PM, Neels J Hofmeyr wrote:
> An svn:externals dir, first checked out onto an already versioned target dir
> (during update), blows away local modifications.
>
[...]
signature.asc
Description: OpenPGP digital signature
On Fri, Sep 2, 2011 at 17:31, Hyrum K Wright wrote:
> On Fri, Sep 2, 2011 at 4:17 PM, Greg Stein wrote:
>...
>> Hyrum -- was your question answered? In particular, my thoughts around
>> using set_text() rather than deltas is best explained by this message
>> in the thread Stefen referenced:
>> h
On Fri, Sep 2, 2011 at 4:17 PM, Greg Stein wrote:
> On Thu, Sep 1, 2011 at 17:17, Stefan Sperling wrote:
>> On Thu, Sep 01, 2011 at 01:49:18PM -0500, Hyrum K Wright wrote:
>>> Quick question: is there a method via Ev2 to set text deltas? I see
>>> svn_editor_set_text(), but that appears to just
On Thu, Sep 1, 2011 at 17:17, Stefan Sperling wrote:
> On Thu, Sep 01, 2011 at 01:49:18PM -0500, Hyrum K Wright wrote:
>> Quick question: is there a method via Ev2 to set text deltas? I see
>> svn_editor_set_text(), but that appears to just apply full texts to
>> the target (via the given stream)
On Fri, Sep 2, 2011 at 12:35, Philip Martin wrote:
> Philip Martin writes:
>
>> The query STMT_SELECT_NODE_CHILDREN_WALKER_INFO as used in 1.7
>>
>> SELECT local_relpath, op_depth, presence, kind
>> FROM nodes
>> WHERE wc_id = ?1 AND parent_relpath = ?2
>> GROUP BY local_relpath
>>
On Fri, Sep 2, 2011 at 13:18, Mark Phippard wrote:
> Pardon my ignorance, but in a scenario like this where we want to just
> change some of the indexes, aren't we able to just bump the WC format
> on the fly automatically? IOW, can't we just make a format 30 with
> all these index changes and ha
On 09/02/2011 12:02 PM, Mark Phippard wrote:
On Fri, Sep 2, 2011 at 11:42 AM, Philip Martin
wrote:
Yes, that's why I think we can delete them. However we rarely write to
these tables so the overhead of having the superfluous index is
negligible. There is no real need to remove them from 1.7
On 09/02/2011 01:06 PM, Philip Martin wrote:
>> + Fix issue #4003 ("'svn patch' seems unable to delete properties").
>> + Justification:
>> + This fixes a lack of consistency with how emptied file contents
>> + are handled.
>> + Notes:
>> + r1164517 adds the XFail regression tes
Mark Phippard writes:
> Pardon my ignorance, but in a scenario like this where we want to just
> change some of the indexes, aren't we able to just bump the WC format
> on the fly automatically? IOW, can't we just make a format 30 with
> all these index changes and have it automatically upgrade
Pardon my ignorance, but in a scenario like this where we want to just
change some of the indexes, aren't we able to just bump the WC format
on the fly automatically? IOW, can't we just make a format 30 with
all these index changes and have it automatically upgrade any format
29 WC it comes across
cmpil...@apache.org writes:
> Author: cmpilato
> Date: Fri Sep 2 15:30:04 2011
> New Revision: 1164581
>
> URL: http://svn.apache.org/viewvc?rev=1164581&view=rev
> Log:
> Propose the issue #4003 fixes for backport.
>
> Modified:
> subversion/branches/1.7.x/STATUS
>
> Modified: subversion/bran
By the way, although I haven't been that involved in this discussion,
I'd just like to point out that this is a textbook example of why we
ask people to test the prereleases and release candidates. I wish
more people would.
Thanks for the good discussion and followup; this will probably be
fixed
Philip Martin writes:
> The query STMT_SELECT_NODE_CHILDREN_WALKER_INFO as used in 1.7
>
>SELECT local_relpath, op_depth, presence, kind
>FROM nodes
>WHERE wc_id = ?1 AND parent_relpath = ?2
>GROUP BY local_relpath
>ORDER BY op_depth DESC
>
> performs poorly and doesn't scale
> Mark Phippard wrote on Fri, Sep 02, 2011 at 12:02:02 -0400:
> > On Fri, Sep 2, 2011 at 11:42 AM, Philip Martin
> > wrote:
> > > Hyrum K Wright writes:
> > >
> > >> sqlite> select * from sqlite_master where type = 'index' and
> > >> tbl_name = 'WCROOT';
> > >> index|sqlite_autoindex_WCROOT_1
Mark Phippard wrote on Fri, Sep 02, 2011 at 12:02:02 -0400:
> On Fri, Sep 2, 2011 at 11:42 AM, Philip Martin
> wrote:
> > Hyrum K Wright writes:
> >
> >> sqlite> select * from sqlite_master where type = 'index' and
> >> tbl_name = 'WCROOT';
> >> index|sqlite_autoindex_WCROOT_1|WCROOT|8|
> >>
On Fri, Sep 2, 2011 at 11:42 AM, Philip Martin
wrote:
> Hyrum K Wright writes:
>
>> sqlite> select * from sqlite_master where type = 'index' and
>> tbl_name = 'WCROOT';
>> index|sqlite_autoindex_WCROOT_1|WCROOT|8|
>> index|I_LOCAL_ABSPATH|WCROOT|9|CREATE UNIQUE INDEX I_LOCAL_ABSPATH
>> ON W
Hyrum K Wright writes:
> sqlite> select * from sqlite_master where type = 'index' and
> tbl_name = 'WCROOT';
> index|sqlite_autoindex_WCROOT_1|WCROOT|8|
> index|I_LOCAL_ABSPATH|WCROOT|9|CREATE UNIQUE INDEX I_LOCAL_ABSPATH
> ON WCROOT (local_abspath)
>
> would both indicate there are two ind
writes:
> That definitely improved the performance. The time it takes to run
> went from 6+ minutes to 1m7s. It's pretty much the same speed as the
> individual queries now. The performance is still significantly worse
> than 1.6.17 was and I don't know if that should be addressed.
Thanks for
On Fri, Sep 2, 2011 at 9:30 AM, Philip Martin
wrote:
> The query STMT_SELECT_NODE_CHILDREN_WALKER_INFO as used in 1.7
>
> SELECT local_relpath, op_depth, presence, kind
> FROM nodes
> WHERE wc_id = ?1 AND parent_relpath = ?2
> GROUP BY local_relpath
> ORDER BY op_depth DESC
>
> performs
That definitely improved the performance. The time it takes to run went from
6+ minutes to 1m7s. It's pretty much the same speed as the individual queries
now. The performance is still significantly worse than 1.6.17 was and I don't
know if that should be addressed.
-Original Message
"Bert Huijben" writes:
> Another option (good or bad) would be to just update the code to create
> format 29 working copies to create different indexes.
>
> Our use of SQL would ensure that we would get the same result with the old
> or new indexes, but working copies created with newer clients w
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: vrijdag 2 september 2011 16:30
> To: dev@subversion.apache.org
> Subject: SQL indices a WC format bump and 1.7
>
> The query STMT_SELECT_NODE_CHILDREN_WALKER_INFO as used in 1.7
>
>SELECT local_re
The query STMT_SELECT_NODE_CHILDREN_WALKER_INFO as used in 1.7
SELECT local_relpath, op_depth, presence, kind
FROM nodes
WHERE wc_id = ?1 AND parent_relpath = ?2
GROUP BY local_relpath
ORDER BY op_depth DESC
performs poorly and doesn't scale well with working copy size. This
cause
On 09/01/2011 05:33 PM, Stefan Sperling wrote:
> On Thu, Sep 01, 2011 at 04:43:45PM -0400, C. Michael Pilato wrote:
>> While documenting 'svn patch' for the book, I noticed something. While 'svn
>> patch' will automatically schedule a file for deletion when it removes all
>> that file's lines, it
Attaching an updated tweaked script...
Regards
Prabhu
On Friday 19 August 2011 11:45 AM, Prabhu Gnana Sundar wrote:
Correcting the issue number as #3961...
On Thursday 18 August 2011 08:32 PM, Prabhu Gnana Sundar wrote:
Hi all,
With reference to my earlier discussions in
http://svn.haxx.s
Thanks Vijay for the detailed explanation...
I am attaching the patch for the script with minor tweaks...
Regards
Prabhu
On Friday 02 September 2011 04:13 PM, vijay wrote:
Actually, there are two issues to be noted.
1.Bug with neon (Reproducible in Ubuntu 10.10, svn 1.6.12, neon
0.29.3/GN
On Friday 02 September 2011 03:42 PM, Daniel Shahaf wrote:
Observations after immense exploration by Vijay and me...
I am using OpenSSL0.9.8o and Neon0.27. The problem is that this
version of OpenSSL does not have the SNI support whereas this
version of neon has a (broken) default SNI support.
Philip Martin writes:
> Philip Martin writes:
>
>> So that indicates that we
>> have a scaling problem, and I suspect the ORDER/GROUP part of
>> STMT_SELECT_NODE_CHILDREN_WALKER_INFO. I don't know whether that is
>> enough to explain the extreme runtime you are getting.
>
> Michael, are you bui
Prabhu Gnana Sundar wrote on Fri, Sep 02, 2011 at 11:54:29 +0530:
> On Monday 22 August 2011 09:37 AM, Prabhu Gnana Sundar wrote:
> >On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote:
> >>I tried your patch against
> >>https://svn.eu.apache.org/repos/asf/subversion/README
> >>(which uses a n
이수민 writes:
> $ make EXTRA_LDFLAGS=-lz
> cd subversion/svn && /bin/sh
> /home/citest/subversion-1.7.0-rc2/libtool --tag=CC --silent
> --mode=link gcc -all-static -static -g -O2 -g -O2 -pthread
> -Werror=implicit-function-declaration -lz -rpath
> /home/citest/target/svn/lib -o svn add
I tried first when beta2 released. see:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201108.mbox/%3ccacfzxxbch01dgaxqnsvdsujtp-0y5juq+zyccfuw69nvrm3...@mail.gmail.com%3E
I think problem not solved yet.
My Operating System dosen't have zlib in standard path.
And I can't install it becau
Philip Martin writes:
> So that indicates that we
> have a scaling problem, and I suspect the ORDER/GROUP part of
> STMT_SELECT_NODE_CHILDREN_WALKER_INFO. I don't know whether that is
> enough to explain the extreme runtime you are getting.
Michael, are you building 1.7 from source? Will you t
34 matches
Mail list logo
