On 03.03.2011 12:53, Arnout van Meer wrote:
On 3 March 2011 11:42, Arnout van Meer<rr2...@splashdamage.com> wrote:
On 3 March 2011 08:36, Stefan Fuhrmann<eq...@web.de> wrote:
Hi Arnout,
Thanks for your review! See my answers below.
-- Stefan^2.
On 28.02.2011 23:36, Arnout van Meer wrote:
On 23 February 2011 08:43, Stefan Fuhrmann<stefanfuhrm...@alice-dsl.de>
wrote:
List of integration branches:
-----------------------------
integrate-is-cachable
- replace the fixed 1MB limit to the cachable full-text
size in FSFS with a cache-specific implementation
integrate-partial-getter
- allows access to sub-structures of cached items
- fixes the O(N^2) performance issue with reports on
large directories
integrate-readline-speedup
- very local change
- significant speedup in parsing any FSFS structure
(e.g. directories) other than full-texts and deltas
integrate-txdelta-caching
- implements caching to the txdelta hunks
- enabled for svnadmin only (speedup of dump / verify)
I'm currently integrating these locally to do some performance related
tests, noticed the following few issues (note that I merged the
partial-getter branch before the is-cachable branch, that way code
ends up meeting the performance branch order):
integrate-partial-getter, in cache-memcache.c, in memcache_get_partial:
mc_key = build_key(cache, key, subpool);
should read:
SVN_ERR(build_key(&mc_key, cache, key, subpool));
This was caused by a change in function signatures on
/trunk last December. For some reason, my compiler
didn't even issue a warning here.
Fixed in r1076552.
Because the code in question is not being used for now
(memcached is only used for full-text caching, if at all),
I will do some manual testing here before the merge.
integrate-txdelta-caching causes a test failure:
START: authz_tests.py
CMD: svnadmin create svn-test-work/local_tmp/repos --bdb-txn-nosync
CMD:
/home/avmeer/dev/subversion/performance-test/subversion/svnadmin/svnadmin
create svn-test-work/local_tmp/repos --bdb-txn-nosync exited with 127
<TIME = 0.115648>
/home/avmeer/dev/subversion/performance-test/subversion/svnadmin/.libs/lt-svnadmin:
error while loading shared libraries: libsvn_fs_util-1.so.0: cannot
open shared object file: No such file or directory
Traceback (most recent call last):
File "./build/run_tests.py", line 585, in<module>
main()
File "./build/run_tests.py", line 578, in main
failed = th.run(args[2:])
File "./build/run_tests.py", line 135, in run
failed = self._run_test(prog, cnt, len(list)) or failed
File "./build/run_tests.py", line 467, in _run_test
(LINE_LENGTH - len(test_info)))
File "./build/run_tests.py", line 413, in _run_py_test
test_selection=test_selection)
File
"/home/avmeer/dev/subversion/performance-test/subversion/tests/cmdline/svntest/main.py",
line 1713, in execute_tests
svntest.actions.setup_pristine_greek_repository()
File
"/home/avmeer/dev/subversion/performance-test/subversion/tests/cmdline/svntest/actions.py",
line 59, in setup_pristine_greek_repository
main.create_repos(main.pristine_greek_repos_dir)
File
"/home/avmeer/dev/subversion/performance-test/subversion/tests/cmdline/svntest/main.py",
line 734, in create_repos
raise SVNRepositoryCreateFailure("".join(stderr).rstrip())
svntest.main.SVNRepositoryCreateFailure:
/home/avmeer/dev/subversion/performance-test/subversion/svnadmin/.libs/lt-svnadmin:
error while loading shared libraries: libsvn_fs_util-1.so.0: cannot
open shared object file: No such file or directory
That looks like your build is broken.
Did you make clean& autobuild.sh?
What OS are you using? On my LINUX
box, static and dynamic builds work.
-- Stefan^2.
Hey Stefan,
All my tests were ran within a VMWare virtual machine with a pretty
much clean, minimal installation of Debian Squeeze. Only packages
installed where the -dev ones related to compiling svn.
make check works for clean trunk 1.7 and for your other branches, but
consistently fails on the txdelta-caching branch.
- Arnout
Two more things you might want to know: I'm running this with a 64 bit
toolchain ('amd64' within the debian environment) and rather than
compiling on your branch, I merged it into the trunk and
compiled/checked from there.
I identified the caused and fixed it in r1078213.
Thanks for being so persistent ;)
-- Stefan^2.
