Re: svn commit: r1080489 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql

2011-03-11 Thread Greg Stein
This is a great simplification, but it makes me wonder... how did that original version even get conceived? On Mar 11, 2011 3:53 AM, wrote: > Author: julianfoad > Date: Fri Mar 11 08:53:14 2011 > New Revision: 1080489 > > URL: http://svn.apache.org/viewvc?rev=1080489&view=rev > Log: > Simplify a S

Re: svn commit: r1080489 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql

2011-03-11 Thread Branko Čibej
On 11.03.2011 12:05, Greg Stein wrote: > This is a great simplification, but it makes me wonder... how did that > original version even get conceived? Looks like someone took a hint my NODES_CURRENT view but didn't understand why it was more complicated than this one. :) -- Brane

Re: [PATCH] Make translator happy - was - Re: svn commit: r1052029 - /subversion/trunk/subversion/libsvn_repos/commit.c

2011-03-11 Thread Philip Martin
Dongsheng Song writes: > [[[ > * subversion/libsvn_repos/commit.c: Make translator happy. (svn_repos__post_commit_error_str): Copy string into correct pool, tweak error text to make translator happy. The pool change should be mentioned in the log. +1 to commit -- Philip

[PATCH] Doc string for svn_wc__db_node_hidden()

2011-03-11 Thread Julian Foad
A second pair of eyes, please? [[[ * subversion/libsvn_wc/wc_db.h (svn_wc__db_node_hidden): Improve the doc string, not to send the reader to a chain of old WC-1 documentation. Index: subversion/libsvn_wc/wc_db.h === --- subver

Re: [PATCH] Doc string for svn_wc__db_node_hidden()

2011-03-11 Thread Philip Martin
Julian Foad writes: > -/* An analog to svn_wc__entry_is_hidden(). Set *HIDDEN to TRUE if > - LOCAL_ABSPATH in DB "is not present, and I haven't scheduled something > - over the top of it." */ > +/* Set *HIDDEN to TRUE if LOCAL_ABSPATH in DB "is not present, and I haven't > + scheduled some

Re: [PATCH] Add --dry-run flag to "svn update" client command

2011-03-11 Thread Kamesh Jayachandran
Hi All, I reviewed the patch and I am fine with it. We did not hear any technical objections for this patch so far. Bert said we can implement it via separate dry_run editor but it would end up copying the code from subversion/libsvn_wc/update_editor.c as we need access to wc. Anyways we ha

[PATCH] Add a test to cover the regression introduced in r1075802

2011-03-11 Thread Arwin Arni
Hi All, This patch adds a test to make sure that conflict resolution files are not created in the event of a *dry-run* merge that has binary file conflicts. The relevant discussion on dev@ is here -> http://svn.haxx.se/dev/archive-2011-03/0145.shtml Regards, Arwin Arni

Re: [PATCH] Add a test to cover the regression introduced in r1075802

2011-03-11 Thread Arwin Arni
On Friday 11 March 2011 08:26 PM, Arwin Arni wrote: Hi All, This patch adds a test to make sure that conflict resolution files are not created in the event of a *dry-run* merge that has binary file conflicts. The relevant discussion on dev@ is here -> http://svn.haxx.se/dev/archive-2011-03/

Re: [PATCH] Add a test to cover the regression introduced in r1075802

2011-03-11 Thread C. Michael Pilato
I'm having trouble getting the patch to apply cleanly, but don't sweat it -- I'll apply it by hand. On 03/11/2011 10:03 AM, Arwin Arni wrote: > On Friday 11 March 2011 08:26 PM, Arwin Arni wrote: >> Hi All, >> >> This patch adds a test to make sure that conflict resolution files are not >> created

Re: [PATCH] Add a test to cover the regression introduced in r1075802

2011-03-11 Thread C. Michael Pilato
On 03/11/2011 10:03 AM, Arwin Arni wrote: > Index: ../subversion/tests/cmdline/merge_tests.py > === > --- ../subversion/tests/cmdline/merge_tests.py(revision 1080126) > +++ ../subversion/tests/cmdline/merge_tests.py(wor

Re: svn commit: r1080489 - /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql

2011-03-11 Thread Stefan Sperling
On Fri, Mar 11, 2011 at 12:17:38PM +0100, Branko Čibej wrote: > On 11.03.2011 12:05, Greg Stein wrote: > > This is a great simplification, but it makes me wonder... how did that > > original version even get conceived? > > Looks like someone took a hint my NODES_CURRENT view but didn't > understan

wc_db API discussion

2011-03-11 Thread Greg Stein
On IRC, there was a discussion about the wc_db API. In particular whether to have lots of query functions, or to have the caller sort it out. As Bert noted, my original intent was to provide the caller with enough information and let it sort everything out. That keeps the API cleaner, and it also m

our Apache Overlords

2011-03-11 Thread Greg Stein
By Simon Phipp's scale, Apache rates a perfect 10. http://webmink.com/2011/03/11/is-apache-open-by-rule/ And he gives us a little shout-out :-P Cheers, -g (of course, there is debate on his Open By Rule stuff, but hey... it's at least *something* to try and measure projects)

Re: wc_db API discussion

2011-03-11 Thread Branko Čibej
On 11.03.2011 20:13, Greg Stein wrote: > I also don't like to see structures like svn_wc__db_info_t. We had a > big problem with the entry_t, and things like info_t will continue to > propagate that broken model. By definition, to use that structure a > query must be done against both NODES and ACT

Re: wc_db API discussion

2011-03-11 Thread Mark Phippard
2011/3/11 Branko Čibej : > On 11.03.2011 20:13, Greg Stein wrote: >> I also don't like to see structures like svn_wc__db_info_t. We had a >> big problem with the entry_t, and things like info_t will continue to >> propagate that broken model. By definition, to use that structure a >> query must be

wc_db performance (was: wc_db API discussion)

2011-03-11 Thread Greg Stein
2011/3/11 Branko Čibej : > This comment is somewhat orthogonal to the API discussions, but as I've > noted before ... after my relatively brief sojourn in wc-db, I came to > the conclusion that having separate NODES and ACTUAL_NODE tables is > going to be a perpetual impediment to really speeding u

Re: wc_db performance (was: wc_db API discussion)

2011-03-11 Thread Branko Čibej
On 12.03.2011 01:29, Greg Stein wrote: > 2011/3/11 Branko Čibej : >> This comment is somewhat orthogonal to the API discussions, but as I've >> noted before ... after my relatively brief sojourn in wc-db, I came to >> the conclusion that having separate NODES and ACTUAL_NODE tables is >> going to b

Re: wc_db performance (was: wc_db API discussion)

2011-03-11 Thread Branko Čibej
On 12.03.2011 01:11, Mark Phippard wrote: > I am glad you sent this because I was getting ready to send an email > to see if anyone is looking into the suggestions you have made here. > I think we have to get this work done soon. We cannot release with > performance like it is. How do we define t

Re: wc_db performance (was: wc_db API discussion)

2011-03-11 Thread Greg Stein
2011/3/11 Branko Čibej : > On 12.03.2011 01:29, Greg Stein wrote: >... >> So. Not a premature optimization, but a design choice. > > Six of one, half a dozen of the other. ACTUAL is just another op-depth > with a few extra attributes, so let's compromise and call it an > implementation choice, rath

Re: wc_db performance (was: wc_db API discussion)

2011-03-11 Thread Greg Stein
2011/3/11 Branko Čibej : >... > For the second task, I think the first order of business is to change > the wc-db tree crawler to do one query instead of zillions, or at least, > where several queries are required, to do them all in one transaction. stsp has been working this recently. Killing the