RE: svn commit: r35771 - in trunk/subversion: include/private libsvn_fs_fs libsvn_subr

> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: woensdag 11 februari 2009 11:54
> To: Bert Huijben
> Cc: hyrum_wright_at_mail.utexas.edu; dev_at_subversion.tigris.org
> Subject: Re: svn commit: r35771 - in trunk/subversion: include/private
> libsvn_fs_fs libsvn_subr
>
> Ugh. That would be a very hard-to-see control flow. Weird little
> untracable side effects.

In the normal flow (no errors) you would just commit or rollback; it would
only add a defined rollback behavior on pool cleanup for the case where it
wasn't before.

I don't see how that would make things harder than your previous suggestions
on moving a file on pool cleanup, etc.

And in many cases you would have a sub or iterpool that has the same
lifetime as the transaction, so I can't think of any real surprises..

Just... when anything unexpected goes wrong... it would also give a defined
behavior to external code that clears the apr pools on a
SVN_ERR_MALFUNCTION_NO_RETURN() that is turned in a C++ exception or
something.

Crashing Visual Studio, Eclipse or anything else that might contain hours of
work, on just a serf operation that receives some garbage data (or some
null reference in another layer) is not an option in many cases.

And I don't know what our current behavior on open sqlite sessions is on
pool cleanups.

(At first glance it looks like it just stops looking at sqlite.. keeping
current transactions open... and makes sqlite block other transactions from
this and other processes).

        Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1138626
Received on 2009-02-11 13:11:33 CET