John Barstow <John_Barstow@gfsg.co.nz> writes:
> On reviewing my logs, the 'special meaning' is running out of memory.
> Specifically, adding 981 files that total about 10 MB on-disk resulted in
> over 1.16GB of memory use when doing an update - versus about 15MB memory
> use getting the same files as a checkout.
>
> That's a pretty serious leak.
> And, I might add, occurs in build 3597 on Win32.
Yup, I get the same leak on Unix. An update of a working copy
containing 400 small files in a single directory, where the update
changes all 400 files, used hundreds of MB before I killed it. The
problem occurs when using ra_dav but not when using ra_local. Total
size of the working copy 6.5MB, that's including the text bases.
Another bug. When I interrupted the update I was left with a locked
working copy, and when I ran cleanup it failed
$ svn cleanup wc
../svn/subversion/libsvn_wc/log.c:286: (apr_err=155009, src_err=0)
svn: Problem running log
svn: in directory wc
../svn/subversion/libsvn_wc/log.c:1160: (apr_err=155009, src_err=0)
svn: start_handler: error processing command 'modify-entry' in wc
../svn/subversion/libsvn_wc/log.c:580: (apr_err=155009, src_err=0)
svn: error merge_syncing entry `foo322'
../svn/subversion/libsvn_subr/io.c:1669: (apr_err=17, src_err=0)
svn: File exists
svn: svn_io_file_open: can't open `wc/.svn/tmp/entries'
The problem is in svn_wc__entries_write, it calls
svn_wc__open_adm_file passing APR_WRITE | APR_EXCL. I think that's a
bug. APR_WRITE causes the .svn/tmp area to be used, so we should not
use APR_EXCL.
Manually removing the .svn/tmp/entries file allowed cleanup to run,
but we should not be encouraging people to do that sort of thing, some
of the .svn/tmp files are necessary for cleanup.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 1 00:49:30 2002