On Fri, Jun 1, 2012 at 5:52 PM, Bert Huijben wrote:
>> -Original Message-
>> From: Greg Stein [mailto:gst...@gmail.com]
>> Sent: vrijdag 1 juni 2012 23:46
>> To: Philip Martin
>> Cc: dev@subversion.apache.org; Bert Huijben
>> Subject: Re: svn commit: r1340318 - in /subversion/trunk/subvers
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: vrijdag 1 juni 2012 23:46
> To: Philip Martin
> Cc: dev@subversion.apache.org; Bert Huijben
> Subject: Re: svn commit: r1340318 - in /subversion/trunk/subversion:
> libsvn_client/status.c svn/status-cmd.c tests/cmdl
On Fri, Jun 1, 2012 at 5:22 PM, Philip Martin
wrote:
> Greg Stein writes:
>
>> On Fri, May 18, 2012 at 8:21 PM, wrote:
>>> Author: rhuijben
>>> Date: Sat May 19 00:21:31 2012
>>> New Revision: 1340318
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1340318&view=rev
>>> Log:
>>> Avoid an unneeded
Greg Stein writes:
> On Fri, May 18, 2012 at 8:21 PM, wrote:
>> Author: rhuijben
>> Date: Sat May 19 00:21:31 2012
>> New Revision: 1340318
>>
>> URL: http://svn.apache.org/viewvc?rev=1340318&view=rev
>> Log:
>> Avoid an unneeded ancestor check in the status walker. This has the added
>> benefi
On Fri, May 18, 2012 at 8:21 PM, wrote:
> Author: rhuijben
> Date: Sat May 19 00:21:31 2012
> New Revision: 1340318
>
> URL: http://svn.apache.org/viewvc?rev=1340318&view=rev
> Log:
> Avoid an unneeded ancestor check in the status walker. This has the added
> benefit that api users can now see a
On Thu, May 31, 2012 at 5:28 AM, wrote:
>...
> +++ subversion/trunk/subversion/tests/cmdline/svntest/main.py Thu May 31
> 09:28:13 2012
> @@ -934,18 +934,23 @@ def canonicalize_url(input):
> return input
>
>
> -def create_python_hook_script(hook_path, hook_script_code):
> +def create_python_
Hi,
Again a post about some crash dumps that were sent for TSVN:
When upgrading a working copy, there's an abort() called here:
subversion\subversion\libsvn_wc\util.c, 300：
(svn_uri_is_canonical(repos_url, pool) &&
svn_relpath_is_canonical(path_in_repos) && SVN_IS_VALID_REVNUM(peg_rev))
prob
On Fri, Jun 1, 2012 at 9:58 AM, Philip Martin
wrote:
> SVNParentPath and AuthzSVNReposRelativeAccessFile make doing it at
> config-time a bit complicated. Would the server scan the SVNParentPath
> directory to locate all the repositories? A repository created later
> would require a reload?
For
Philip Martin writes:
> Is COPY_TWO_BYTES a significant optimisation?
r1325896 implies this is most significant for ra_svn. So I compared the
testsuite over ra_svn built with the "fast" code and the "slow" code.
The CPU used by the testsuite and svnserve was:
"fast" code
749.93user 404.
Justin Erenkrantz writes:
> On Thu, May 31, 2012 at 2:47 AM, Ivan Zhakov wrote:
>> Currently Subversion reads authz file per-connection, not per-request.
>
> Even that's probably still wrong. A better solution would be to parse
> it at config-time - but, that would mean we'd want to do some lev
[Bert Huijben]
> Then there is a different problem that you found: We have triggers
> that detect invalid database states when SVN_DEBUG is defined in
> wc_db_wcroot.c. These are currently depend on parent nodes being
> changed before their children, which is not guaranteed by the SQL
> specifica
On Thu, May 31, 2012 at 2:47 AM, Ivan Zhakov wrote:
> Currently Subversion reads authz file per-connection, not per-request.
Even that's probably still wrong. A better solution would be to parse
it at config-time - but, that would mean we'd want to do some level of
checking/invalidity on a per-c
rhuij...@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=1345158&view=rev
> Log:
> Avoid creating another ra session in most code paths in the merge code. At the
> same time fix accidentally opening the ra session with a non read-only working
> copy.
>
> This patch relies on the ra.c fi
rhuij...@apache.org wrote:
> URL: http://svn.apache.org/viewvc?rev=1344833&view=rev
> Log:
> Reuse an existing ra session when fetching the common ancestor of two urls
> from the merge and switch handling.
>
> * subversion/libsvn_client/client.h
> (svn_client__get_youngest_common_ancestor): All
Branko Čibej writes:
> On 01.06.2012 14:22, Philip Martin wrote:
>> GCC gives a compiler warning where the COPY_TWO_BYTES macro is used. A
>> typical warning is:
>>
>> ../src/subversion/libsvn_subr/string.c:971:11: warning: dereferencing
>> type-punned pointer will break strict-aliasing rules [
On Fri, Jun 01, 2012 at 07:52:08AM -0500, Hyrum K Wright wrote:
> We've talked elsewhere about bumping the required version to 3.7.12 to
> take advantage of further improvements which dramatically impact us.
+1, this makes sense for 1.8.
> My only reason for not doing so just yet is that the buil
On Fri, Jun 1, 2012 at 6:19 AM, Bert Huijben wrote:
...
>
> I don’t see a problem with bumping the requirement to 3.7.9, but that
> decision should be made here on this list. Not by me :)
We've talked elsewhere about bumping the required version to 3.7.12 to
take advantage of further improvements
Please consider following patch for trunk:
[[[
JavaHL: Add SVN_JNI_STRING macro to reduce amount of code necessary to
declare
JNIStringHolder and check for exceptions
[ in subversion/bindings/javahl/native ]
* JNIStringHolder.h
(SVN_JNI_STRING): New macro to declare JNIStringHolder local varia
On 01.06.2012 14:22, Philip Martin wrote:
> GCC gives a compiler warning where the COPY_TWO_BYTES macro is used. A
> typical warning is:
>
> ../src/subversion/libsvn_subr/string.c:971:11: warning: dereferencing
> type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
>
GCC gives a compiler warning where the COPY_TWO_BYTES macro is used. A
typical warning is:
../src/subversion/libsvn_subr/string.c:971:11: warning: dereferencing
type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
COPY_TWO_BYTES(dest, decimal_table[(apr_size_t)numb
SQLite works correctly for Subversion since 3.6.8 (which made the triggers
work the way we use them).
SQLite 3.6.8 - 3.7.8 don’t use the query plans we expect them to use for
normal performance. In simple words operations that should operate on a
single node, may touch every node at every op-depth
And why is 3.7.9 now required?
Performance? Or bug fixes?
On Fri, Jun 1, 2012 at 5:25 AM, Greg Stein wrote:
> I'm unclear here.
>
> Is 3.7.9 *required* ? ... or is that just for a better query planner?
>
> If this trigger is firing for me only in the maintenance builds, then
> what is it really
I'm unclear here.
Is 3.7.9 *required* ? ... or is that just for a better query planner?
If this trigger is firing for me only in the maintenance builds, then
what is it really telling me?
Come on, Bert. What is going on? Do we need to REQUIRE 3.7.9 or NOT?
Don't just feed me little bits of info
The required fix is in 3.7.9. (http://www.sqlite.org/releaselog/3_7_9.html.
Probably the 'Enhanced the query planner so that it can factor terms in and
out of OR expressions in the WHERE clause in an effort to find better
indices.' Change)
These triggers are temporary triggers inserted when you
On Jun 1, 2012 3:56 AM, "Bert Huijben" wrote:
>
>
>
> > -Original Message-
> > From: Greg Stein [mailto:gst...@gmail.com]
> > Sent: vrijdag 1 juni 2012 9:28
> > To: dev@subversion.apache.org
> > Subject: validity check error? huh?
> >
> > Any ideas on why I'm seeing this now?
> >
> >
> > $
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: vrijdag 1 juni 2012 9:28
> To: dev@subversion.apache.org
> Subject: validity check error? huh?
>
> Any ideas on why I'm seeing this now?
>
>
> $ ./basic_tests.py 1
> W: subversion/svn/delete-cmd.c:92: (apr_err=20
Any ideas on why I'm seeing this now?
$ ./basic_tests.py 1
W: subversion/svn/delete-cmd.c:92: (apr_err=200035)
W: subversion/svn/util.c:913: (apr_err=200035)
W: subversion/libsvn_client/delete.c:482: (apr_err=200035)
W: subversion/libsvn_client/delete.c:383: (apr_err=200035)
W: subversion/libsvn_
27 matches
Mail list logo
