On Wed, Nov 21, 2012 at 2:07 AM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Not destroying iterpool would cause rep_write_cleanup() (pool cleanup > handler) not to fire [according to breser], hence not call > unlock_proto_rev(), hence not clear the "being_written" flag in the txn > object. That object lives in the fs_fs_shared_data_t (which outlives > svn_fs_t handles) so subsequent attempts to commit that transaction > within the same process before clearing the pool would spuriously fail.
This is true of the fsfs change but the client change is not actually required. See my lengthier email in response to Bert.