Sorry for the long delay getting back. I finally got around to
compiling in your patch and it doesn't appear to help - although I'm now
getting "obstructed updates" even after doing a clean co, so I haven't
been able to run a job to completion. It is still taking up near 100M
of memory and growing fast before it stops. It seems to me that the
leak is related to reading the local working copy files, not with
accessing the repository, and that whether I'm using a local file:/// or
http:// URL for the repository makes no difference. Win32 vs Unix also
seems to not matter. These operations have given me trouble:
cvs2svn.py using local repository
pset whether fs or http (but that doesn't access the repos...)
commit whether fs or http.
These operations seem to perhaps have a very small leak, but small
enough to not matter for even my 2G repository.
revert
cleanup
co
I haven't had a chance yet to try the mmacek branch. I'll see if I can
get to it this weekend (as well as trying the latest head).
Thanks for the reply! Hopefully we can resolve this soon.
Nathan
P.S. Regarding the obstructed updates: Yes I've tried a svnadmin
recover as well as an svn cleanup. Neither help. I think the problem is
related to the memory leak, though, because if I go run the command I
was running and filed on the file which failed individually, it works.
It only fails when doing a large recursive call to set a lot of stuff.
Marko Macek wrote:
> Nathan Sharp wrote:
>
>> I am about 2 days old to subversion, I wasn't even aware that there
>> was a branch with anything I might be interested in. As Donald said,
>> yes, I am using the trunk.
>> I experimented further (thanks to some help I got on the IRC channel)
>> and think I have a workaround now. After running passes 1-3 (and
>> forcibly preventing 4 from running), I took the cvs2svn-data.s-revs
>> file and chopped it into files with 20,000 lines each. By running
>> the script on pass 4 on each file in order, I seem to be able to run
>> successfully, which proves that the problem a) is a memory leak and
>> b) was failing because it ran my system out of memory. The only
>> negative effect of what I did is that right where I split the files
>> (since I just did exactly 20k line files and didn't manually split
>> the files up at a natural commit break) I will end up with an commit
>> which is split in 2, which is minor enough for me not to worry about it.
>> The general belief I heard on the IRC channel is that the memory leak
>> is probably in the swig bindings and not in the cvs2svn.py script
>> itself. I'd be happy to help in any way possible if someone wants to
>> try and fix it.
>>
> Please try the following patch to subversion.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 7 00:47:23 2003