Re: Using Sqlite in libsvn_wc towards Subversion 1.9++

2013-11-17 Thread Branko Čibej
On 18.11.2013 03:50, Justin Erenkrantz wrote: > On Sun, Nov 17, 2013 at 7:34 AM, Bert Huijben > wrote: > > But I would also like to recommend/ask that we start bundling > Sqlite with > Subversion, to allow optimizing for the specific version we use for a > re

Re: Using Sqlite in libsvn_wc towards Subversion 1.9++

2013-11-17 Thread Justin Erenkrantz
On Sun, Nov 17, 2013 at 7:34 AM, Bert Huijben wrote: > But I would also like to recommend/ask that we start bundling Sqlite with > Subversion, to allow optimizing for the specific version we use for a > release without risking future breakage. > If we use the amalgamation, are all of the symbols

[svnbench] Revision: 1542875 compiled Nov 18 2013, 00:22:05 on x86_64-unknown-linux-gnu

2013-11-17 Thread neels
1.8.0@1492600 vs. trunk@1542817 Started at Mon Nov 18 00:26:12 UTC 2013 *DISCLAIMER* - This tests only file://-URL access on a GNU/Linux VM. This is intended to measure changes in performance of the local working copy layer, *only*. These results are *not* generally true for everyone. Charts of t

Add "strict conflicts" merge mode to most wanted list?

2013-11-17 Thread Fredrik Orderud
Over the past year, there have been several discussions regarding undesirable side-effects of the currently (too) "permissive" merge mode on this list. As of today, subversion will silently discard changes (instead of signaling a conflict) under certain merging scenarios. One such problem is out-of

Re: svn commit: r1542741 [1/3] - in /subversion/branches/invoke-diff-cmd-feature: BRANCH-README subversion/include/svn_io.h subversion/libsvn_client/diff.c subversion/svn/svn.c subversion/svnlook/svnl

2013-11-17 Thread Branko Čibej
On 17.11.2013 21:44, Gabriela Gibson wrote: > Thanks Brane, > > no :) plain fact is that I didn't think that changing code I messed up > within the branch and then fixed as significant. We have a policy about log messages, regardless of where the commit is made. That's the long and short of it. If

Re: svn commit: r1542741 [1/3] - in /subversion/branches/invoke-diff-cmd-feature: BRANCH-README subversion/include/svn_io.h subversion/libsvn_client/diff.c subversion/svn/svn.c subversion/svnlook/svnl

2013-11-17 Thread Gabriela Gibson
Thanks Brane, no :) plain fact is that I didn't think that changing code I messed up within the branch and then fixed as significant. I sort of see the branch as a semi-private space, where I do stuff that you can look at, but that doesn't have much meaning (hence me terming N changes in M files

Re: svn commit: r1542741 [1/3] - in /subversion/branches/invoke-diff-cmd-feature: BRANCH-README subversion/include/svn_io.h subversion/libsvn_client/diff.c subversion/svn/svn.c subversion/svnlook/svnl

2013-11-17 Thread Branko Čibej
On 17.11.2013 21:08, Gabriela Gibson wrote: > Thank you Ivan, > > I was blithely assuming that because I was removing trivial changes I > introduced to the branch, that no-one would track them :) Also I was > trying to avoid writing trivial things for people to read. > > The log message is fixed n

Re: svn commit: r1542741 [1/3] - in /subversion/branches/invoke-diff-cmd-feature: BRANCH-README subversion/include/svn_io.h subversion/libsvn_client/diff.c subversion/svn/svn.c subversion/svnlook/svnl

2013-11-17 Thread Gabriela Gibson
Thank you Ivan, I was blithely assuming that because I was removing trivial changes I introduced to the branch, that no-one would track them :) Also I was trying to avoid writing trivial things for people to read. The log message is fixed now. Now I'm curious -- what tools do people use to revi

Re: 1.8.5 up for testing/signing

2013-11-17 Thread Branko Čibej
Summary: +1 to release Platform Mac OS X 10.8.5 Mountain Lion, build 12F45 Standard dependencies: Apple clang(++) 5.0 (clang-500.2.79)/LLVM 3.3svn APR 1.4.5 APR-Util 1.3.12 zlib 1.2.5 httpd 2.2.24 OpenSSL 0.9.8y Java 1.6.0_65 Python 2.

Re: 1.7.14 up for testing/signing

2013-11-17 Thread Branko Čibej
Summary: +1 to release Platform Mac OS X 10.8.5 Mountain Lion, build 12F45 Standard dependencies: Apple clang(++) 5.0 (clang-500.2.79)/LLVM 3.3svn APR 1.4.5 APR-Util 1.3.12 zlib 1.2.5 httpd 2.2.24 OpenSSL 0.9.8y Java 1.6.0_65 Python 2.

Re: 1.8.5 up for testing/signing

2013-11-17 Thread Branko Čibej
Looks like our release process is somewhat broken. Expanded keywords in files in the release tarballs (looking at 1.7.14 and 1.8.5) point to locations on the respective release branch, instead of the tag. IMO, we should always create tarballs from tag checkouts, not release branch checkouts. -- B

Re: svn commit: r1542741 [1/3] - in /subversion/branches/invoke-diff-cmd-feature: BRANCH-README subversion/include/svn_io.h subversion/libsvn_client/diff.c subversion/svn/svn.c subversion/svnlook/svnl

2013-11-17 Thread Ivan Zhakov
On 17 November 2013 18:56, wrote: > Author: gbg > Date: Sun Nov 17 14:56:28 2013 > New Revision: 1542741 > > URL: http://svn.apache.org/r1542741 > Log: > On the invoke-diff-cmd-feature branch: Update BRANCH-README file. > Trivial white space changes to assorted files. > > * BRANCH-README: Update

Re: Using Sqlite in libsvn_wc towards Subversion 1.9++

2013-11-17 Thread Branko Čibej
On 17.11.2013 14:33, Bert Huijben wrote: > >> -Original Message- >> From: Branko Čibej [mailto:br...@wandisco.com] >> Sent: zondag 17 november 2013 14:08 >> To: dev@subversion.apache.org >> Subject: Re: Using Sqlite in libsvn_wc towards Subversion 1.9++ >> >> On 17.11.2013 13:34, Bert Huijb

RE: Using Sqlite in libsvn_wc (partial indexes)

2013-11-17 Thread Bert Huijben
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: zondag 17 november 2013 14:33 > To: 'Branko Čibej'; dev@subversion.apache.org > Subject: RE: Using Sqlite in libsvn_wc towards Subversion 1.9++ > > > > > -Original Message- > > From: Branko Čibej [mailto:

RE: Using Sqlite in libsvn_wc towards Subversion 1.9++

2013-11-17 Thread Bert Huijben
> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: zondag 17 november 2013 14:08 > To: dev@subversion.apache.org > Subject: Re: Using Sqlite in libsvn_wc towards Subversion 1.9++ > > On 17.11.2013 13:34, Bert Huijben wrote: > > Hi, > > > > For Subversion 1.

RE: Using Sqlite in libsvn_wc (introducing sqlite_stat1)

2013-11-17 Thread Bert Huijben
> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: zondag 17 november 2013 14:08 > To: dev@subversion.apache.org > Subject: Re: Using Sqlite in libsvn_wc towards Subversion 1.9++ > > On 17.11.2013 13:34, Bert Huijben wrote: > > Hi, > > > > For Subversion 1.

Re: Using Sqlite in libsvn_wc towards Subversion 1.9++

2013-11-17 Thread Branko Čibej
On 17.11.2013 13:34, Bert Huijben wrote: > Hi, > > For Subversion 1.8 I spend a lot of time optimizing our use of Sqlite in the > working copy to work as optimal as possible with the then Supported range of > Sqlite versions (3.7.12-3.7.19). Then a few months later in Sqlite 3.8.0 a > new que

Using Sqlite in libsvn_wc towards Subversion 1.9++

2013-11-17 Thread Bert Huijben
Hi, For Subversion 1.8 I spend a lot of time optimizing our use of Sqlite in the working copy to work as optimal as possible with the then Supported range of Sqlite versions (3.7.12-3.7.19). Then a few months later in Sqlite 3.8.0 a new query planner was introduced that broke quite a few o