Ugh. That would be a very hard-to-see control flow. Weird little
untracable side effects.
On Tue, Feb 10, 2009 at 00:14, Bert Huijben <b.huijben_at_competence.biz> wrote:
>
>
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: dinsdag 10 februari 2009 4:59
>> To: dev_at_subversion.tigris.org
>> Subject: Re: svn commit: r35771 - in trunk/subversion: include/private
>> libsvn_fs_fs libsvn_subr
>>
>> On Mon, Feb 9, 2009 at 12:52, Hyrum K. Wright <hyrum_at_hyrumwright.org>
>> wrote:
>> >...
>> > +++ trunk/subversion/libsvn_fs_fs/fs_fs.c Mon Feb 9 12:52:35
>> 2009 (r35771)
>> > @@ -5800,31 +5800,35 @@ commit_body(void *baton, apr_pool_t *poo
>> > return SVN_NO_ERROR;
>> > }
>> >
>> > -/* Wrapper around commit_body() which implements SQLite
>> transactions. Arguments
>> > - the same as commit_body().
>> > +/* Baton for use with an sqlite transaction'd commit body. */
>> > +struct commit_sqlite_txn_baton
>> > +{
>> > + struct commit_baton *cb;
>> > + apr_pool_t *pool;
>> > +};
>>
>> You could simplify quite a bit if you just put a pool into the
>> commit_baton structure.
>
> Hyrum,
>
> Why don't you just rollback transactions on pool cleanup?
>
> You could just mark them as already committed with some new function, and
> automatically rollback when the pool is cleaned up before it is committed
> (or when it is rolled back before).
>
> Bert
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1138421
Received on 2009-02-11 11:54:37 CET