Re: svn commit: r1582845 - /subversion/trunk/subversion/libsvn_fs/fs-loader.c

2014-03-29 Thread Philip Martin
"Bert Huijben" writes: > Perhaps it would be easier for all callers if the (inner) handler that > allocates the hash table installs a cleanup handler on it that releases all > the svn_error_t instances on pool cleanup of the release pool? > > Now all callers that have access to the results have t

RE: svn commit: r1582845 - /subversion/trunk/subversion/libsvn_fs/fs-loader.c

2014-03-29 Thread Bert Huijben
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: vrijdag 28 maart 2014 20:57 > To: Bert Huijben > Cc: dev@subversion.apache.org; comm...@subversion.apache.org > Subject: Re: svn commit: r1582845 - > /subversion/trunk/subversion/

Re: svn commit: r1582845 - /subversion/trunk/subversion/libsvn_fs/fs-loader.c

2014-03-28 Thread Philip Martin
"Bert Huijben" writes: >> + expiration_date, steal_lock, pool, pool); >> + >> + if (apr_hash_count(results)) > > Is this function explicitly documented to always set the results value > on all error paths? > > I don't see that in the documentation for svn_fs_lock2? It is now

RE: svn commit: r1582845 - /subversion/trunk/subversion/libsvn_fs/fs-loader.c

2014-03-28 Thread Bert Huijben
> -Original Message- > From: phi...@apache.org [mailto:phi...@apache.org] > Sent: vrijdag 28 maart 2014 18:51 > To: comm...@subversion.apache.org > Subject: svn commit: r1582845 - /subversion/trunk/subversion/libsvn_fs/fs- > loader.c > > Author: philip > Date: Fri Mar 28 17:51:09 2014 >