Re: svn commit: r1694489 [1/2] - in /subversion/trunk: ./ subversion/include/private/ subversion/libsvn_fs_fs/ subversion/libsvn_fs_x/ subversion/libsvn_subr/ subversion/tests/libsvn_subr/

On Thu, Aug 6, 2015 at 3:59 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:

> On 6 August 2015 at 15:54, <stefan2_at_apache.org> wrote:
> > Author: stefan2
> > Date: Thu Aug 6 12:54:36 2015
> > New Revision: 1694489
> >
> > URL: http://svn.apache.org/r1694489
> > Log:
> > Merge the 1.10-cache-improvements development branch to trunk and remove
> > the BRANCH-README file. There were no conflicts.
> >
> > Changes brought by this branch:
> > - Introduce a NULL cache implementation to unify / simplify cache usage
> > - Space and runtime efficiency improvements to the recently introduced
> > full key comparison in membuffer caches.
> >
> Stefan,
>
> Could you please write full log message for this change as required by
> our community guide?
>

This has been discussed before on more than one occasion.
The latest instance that I could find starts here:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201501.mbox/%3CCABw-3YetbY57PngpBGnVbAMkApMd-v4ZGzsAfHe20ZYWi2i%2BTA%40mail.gmail.com%3E

Bottom line: 'svn log -g -r1694489' if you really need to know
the details. For convenience, there is a short summary in the
commit message. This is something people had asked for in
the past.

> Also after this change fs-test.exe fails with assertion in Windows
> 32-bit Debug build:
> [[
> START: fs-test.exe
> Assertion failed: !group || !group->header.used, file
> ..\..\..\subversion\libsvn_subr\cache-membuffer.c, line 1031
> ]]
>

This one is odd because the merge did not touch anything
obviously linked to spare bucket handling. Could be a long-
standing issue.

I failed to reproduce it with a 32 bit debug build on Win64.
Does it fail for you in serial execution mode? Is it deterministic
in that case? Does the attached patch prevent it?

I'm also getting random assertion like this in other tests.
>

That would be expected as this is low-level functionality
which will be used whenever you access repo data.

This commit mixes different unrelated changes, so it's very hard to
> find which part caused assertion.
>

You might try a bisection on the former 1.10-cache-improvements
branch, starting with HEAD (to see whether the branch
or the combination of trunk & branch is to blame).

-- Stefan^2.