With careful effort of stefan2 and myself we've reverted this. It was
mistakenly merged onto the 1.7.x branch not the 1.7.x-r1643074 branch. Not
only that but the merge it says it's doing is not what it did, it was actually
a merge of r1643119 on 1.8.x-r1643074.
I found this only because the mer
Translation status report for trunk@r1643983
lang trans untrans fuzzy obs
--
de2871 2 3 489 +~o
es2263 610 827 527 ++U~~~
fr2567 306
Philip Martin writes:
> My pool-debug build uses my own httpd build from 2.2.x@1562432 while my
> normal build used the system httpd, Debian's 2.2.22-13+deb7u3. It looks
> like some change to mod_dav has added an extra walk over the copy source
> in the pool-debug build and the absence of this w
Philip Martin writes:
> I think this extra walk is pointless most of the time and is just making
> our nominally O(1) copy operation slower. Locks on the copy source do
> not prevent a copy.
Oops! I meant to write "Locks on the copy source held by somebody else
do not prevent a copy".
--
Phil
Philip Martin writes:
> I'm still trying to determine why this
> extra walk is present, perhaps the new version is doing an unnecessary
> walk or perhaps the old version has an unfixed bug.
Debian's httpd doesn't have r1497441 which introduced the extra walk for
copies, apparently to fix PR 5461
Philip Martin writes:
> The problem is easy to reproduce with pool debugging enabled and the
> patch does reduce memory use, but with a normal build I don't see the
> excessive memory in the first place.
My pool-debug build uses my own httpd build from 2.2.x@1562432 while my
normal build used th
On Mon, Dec 08, 2014 at 08:30:31PM +0100, Stefan Fuhrmann wrote:
> Hm. 381 MB are massive, then. Maybe I can find reproduce it
> and help tracking it down with a modified APR.
Yes, we should be able to manage with much less.
Though perhaps what's left is in in mod_dav rather than mod_dav_svn.
> >
On Mon, Dec 08, 2014 at 07:19:57PM +, Philip Martin wrote:
> I have been looking at the proposed 1.8/1.7 backport for issue 4531.
> The problem is easy to reproduce with pool debugging enabled and the
> patch does reduce memory use, but with a normal build I don't see the
> excessive memory in
On Mon, Dec 8, 2014 at 7:46 PM, Stefan Sperling wrote:
> On Mon, Dec 08, 2014 at 06:42:38PM +0100, Stefan Fuhrmann wrote:
> > IOW, pool debugging is nice for tracing allocations but if you
> > want to measure memory consumption on the OS side, turn
> > pool debugging off.
>
> All measurements I m
Stefan Sperling writes:
> Which option are you referring? The SVNInMemoryCacheSize option?
> The doc for that option says "0 deactivates the cache". Is this an error?
http://subversion.apache.org/docs/release-notes/1.7.html#data-caches
"Please note that a cache size of 0 will deactivate the new
Stefan Fuhrmann writes:
> This post has been prompted by issue 4531 and r1643834
> (http://subversion.tigris.org/issues/show_bug.cgi?id=4531
> http://svn.apache.org/viewvc?view=revision&revision=r1643834).
> IOW, pool debugging is nice for tracing allocations but if you
> want to measure memory
On Mon, Dec 08, 2014 at 06:42:38PM +0100, Stefan Fuhrmann wrote:
> IOW, pool debugging is nice for tracing allocations but if you
> want to measure memory consumption on the OS side, turn
> pool debugging off.
All measurements I mentioned in the issue were done with pool debugging
disabled. Measur
This post has been prompted by issue 4531 and r1643834
(http://subversion.tigris.org/issues/show_bug.cgi?id=4531
http://svn.apache.org/viewvc?view=revision&revision=r1643834).
We had a somewhat similar issue with log -v & friends in
summer this year. Now, I dug into the APR code and this
what I fo
Stefan Fuhrmann wrote:
> Julian Foad wrote:
>> So now we need to:
>>
>> * undo the merge of the 1.8.x-r1611379 branch
>
> +1.
r1643849.
>> * re-nominate my original nomination.
>
> +1.
r1643849 and r1643850.
I down-graded all our votes (including my own) from +1 to +0 because whatever
we d
On Mon, Dec 8, 2014 at 5:07 PM, Julian Foad
wrote:
> Stefan Fuhrmann wrote:
> > Looking through ^/subversion/branches, I found that there are many
> > backport branches that are not mentioned in any STATUS file.
> [...]
>
> > 1.8.x
> > Julian: 1.8.x-r1619380 (not modified)
>
> Ugh. Thanks for rep
Stefan Fuhrmann wrote:
> Looking through ^/subversion/branches, I found that there are many
> backport branches that are not mentioned in any STATUS file.
[...]
> 1.8.x
> Julian: 1.8.x-r1619380 (not modified)
Ugh. Thanks for reporting this discrepancy. There is a mess here.
First, it IS modified
Branko Čibej writes:
> On 08.12.2014 13:03, phi...@apache.org wrote:
>> Author: philip
>> Date: Mon Dec 8 12:03:23 2014
>> New Revision: 1643793
>>
>> URL: http://svn.apache.org/r1643793
>> Log:
>> * autogen.sh: Unset CDPATH.
>>
>> Modified:
>> subversion/trunk/autogen.sh
>>
>> Modified: sub
On 08.12.2014 13:03, phi...@apache.org wrote:
> Author: philip
> Date: Mon Dec 8 12:03:23 2014
> New Revision: 1643793
>
> URL: http://svn.apache.org/r1643793
> Log:
> * autogen.sh: Unset CDPATH.
>
> Modified:
> subversion/trunk/autogen.sh
>
> Modified: subversion/trunk/autogen.sh
> URL:
> ht
On Mon, Dec 8, 2014 at 10:44 AM, Naveen Mc wrote:
> Hi,
> I am facing the following issue when i try to sync master and mirror svn
> repositories. Any idea how do i fix this.Is it svn 1.5 known bug? Please
> help.
>
> OS - AIX/Linux
> SVN Version - 1.5
> ERROR:
>- Failed to sync apd repos [ ]
Hi,
I am facing the following issue when i try to sync master and mirror svn
repositories. Any idea how do i fix this.Is it svn 1.5 known bug? Please
help.
OS - AIX/Linux
SVN Version - 1.5
ERROR:
- Failed to sync apd repos [ ].
The assert subroutine failed: window->sview_len == 0 ||
(window->sv
20 matches
Mail list logo
