[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Wed, 11 Feb 2009 13:10:43 +0100

> -----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

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).


Received on 2009-02-11 13:11:33 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.