On 31.10.2010 17:50, Daniel Shahaf wrote:
> I ran 'make svncheck' with memory_cache_size and open_file_count set to
> 1<<27 and 1<<9 respectively in two ways: first with svnserveautocheck
> and second with a manually-started 'svnserve -dTr subversion/tests/cmdline/'.
> I see some unexpected failures in the second run, which aren't present
> in the first run or in trunk.
>
> I tested performance_at_r1029380. (Addendum: I updated to r1029381 and the
> same six tests I report here still fail. I haven't run a full 'make
> check' with r1029381.)
>
>
> In the svnserveautocheck run, all failures seemed expected. (I saw
> three failures: the two tests that fail in all my trunk builds[1], and
> one failure (svnadmin_tests 12) because my build changed some FSFS error
> messages in a manner not to the test's liking.)
>
> However, in the 'svnserve -T' case, I got six failures: the same
> svnadmin_tests 12,13,17 as above, and in addition these:
>
> FAIL: svnadmin_tests.py 20: don't filter mergeinfo revs from incremental dump
> FAIL: svndumpfilter_tests.py 1: reflect dropped renumbered revs in svn:mergeinfo
> FAIL: svndumpfilter_tests.py 5: filter mergeinfo revs outside of dump stream
>
>
> The first of this sees "svn: Found malformed header '0.r15/1698' in revision file"
> during a 'propget -R svn:mergeinfo'.
>
> The third sees "svn: Corrupt node-revision '1-6.0.r6/323'": and
> "svn: Missing id field in node-rev" during a 'propget -R svn:mergeinfo'.
>
> The second sees a more casual error:
>
> DIFF STDOUT (unordered):
> --- EXPECTED STDOUT
> +++ ACTUAL STDOUT
> @@ -1,1 +1,1 @@
> -svn://localhost/svn-test-work/repositories/svndumpfilter_tests-1/trunk -
> +svn://localhost/svn-test-work/repositories/svndumpfilter_tests-1/trunk - /branch1:4-5
> EXCEPTION: SVNLineUnequal
>
>
> I attach the fails.log file of the 'svnserve -T' run.
The root cause for this failure is the revision files being modified /
replaced outside the server. As long as the file handle cache keeps
open APR file handles, those will also keep their internal 4k buffers.
This got fixed in r1037470 by closing all files at the end of the session
except for the ones currently in used by running requests.
It seems to me that we are missing a function to tell svnserve that
the content of a particular repository has been tweaked. On /trunk,
there no way to tell the server that all the data in memcached instances
no longer matches the actual repository content.
-- Stefan^2.
Received on 2010-11-22 02:50:26 CET