It should not be copied,
disclosed to, retained or used by, any other party. If you are not an intended
recipient then please promptly delete this e-mail and any attachment and all
copies and inform the sender. Thank you.
>From 0caacfe898930ecee2a9e97a66d3cbbfb5ac Mon Sep 17 00:00:00 2001
On 09/05/11 21:51, Julian Foad wrote:
> Nick Piper wrote:
>> Add svn_stream_close_on_cleanup(), which will register a stream to be
>> automatically closed when the pool is destroyed.
>
> First impression: the public name makes it sound like a user-level
> thing, but this
This version:
* Makes the new behaviour optional, via stream_close_on_cleanup()
(which the Python API then uses.) (Thanks Bert.)
* Uses apr_pool_cleanup_register() rather than the 'pre' variant, in
order to match the reset of svn and be compatible with older APR (thanks
Philip.)
[[[
Add svn_stre
Thanks for reviewing.
On 09/05/11 15:53, Daniel Shahaf wrote:
> Nick Piper wrote on Mon, May 09, 2011 at 15:31:53 +0100:
>> + /* This is used to close the stream if the pool is being destroyed.
>> + It was first introduced for the Python API, to allow implicit
&
On 09/05/11 12:59, Philip Martin wrote:
> Yes, that would work. An alternative would be to deregister the pool
> cleanup on an explicit close.
Here is a version that does this. It's tested with the existing tests,
plus my small test case, and it stops the leaking.
[[[
Automatically svn_stream_c
On 09/05/11 09:05, Markus Schaber wrote:
> Hi, Hick,
>
>> Von: Piper, Nick [mailto:nick.pi...@logica.com]
>
>> In Python, f is a "file" instance, but that will be converted to a
>> svn_stream_t by swig (by svn_swig_py_make_stream()).
>>
>> That file then goes out of scope in Python, but the fi
On 07/05/11 08:27, Daniel Shahaf wrote:
> Piper, Nick wrote on Sat, May 07, 2011 at 05:00:05 +:
>> I've attached a script which reproduces the problem in a minimal way.
>
> The attachment never made it to the list...
>
> (bad MIME type?)
Sorry for that, a copy is now at https://gist.github
(This doesn't appear to have come through to the list after a day, so
I'm resending it from a different MUA.)
On 01/11/10 15:56, Philip Martin wrote:
> The name should be AuthzSVNReposRelativeAccessFile for consistency with
> SVNReposName.
>
> It should be an error to specify both AuthzSVNAccess
on.
(subreq_bypass, access_checker, check_user_id, auth_checker)
Recognise that it's valid not to have a AuthzSVNAccessFile if
AuthzSVNRepoRelativeAccessFile is used.
]]]
--
Nick Piper MEng MIET RHCE| #define Joint Lead Architect
250 Brook Drive, Green Park, Reading RG2 6UA | United King
9 matches
Mail list logo
