On 11.07.2013 16:31, Michael Pruemm wrote:
> I'm trying to learn to use the svn api via the Python swig bindings
> for 1.8.0. So I wrote some naive code that calls svn_client_log5 and
> in the callback does something like this:
> foreach file in changed_paths:
> The pool passed to svn_client_ls3 is the one passed to the callback
> (I first tried to use svn_client_list3 but the Python bindings lack
> (support for its callback function.)
> This works fine for a while when I access the repository via http://
> but eventually lots of connections are open and the script just hangs
> and doesn't even react to ^C.
> When I access the repository via svn+ssh:// it works fine until I
> reach a commit that touched more than ~512 files. At that point, svn
> is unable to open more connections to the repository, and a process
> listing shows that there are 512 active processes connecting with the
> Apparently, these connections are only closed when the memory pool is
> cleared/destroyed but this behaviour is not documented anywhere. Is
> this a bug?
No. Pools encapsulate all resource management -- including file handles
and sockets (connections), not only allocated memory.
This document explains how pools should be used:
In your example, you should be using an iteration pool.
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
Received on 2013-07-11 17:34:36 CEST