Bert Huijben wrote on Wed, Nov 21, 2012 at 10:36:43 +0100: > > > > -----Original Message----- > > From: svn-r...@apache.org [mailto:svn-r...@apache.org] > > Sent: woensdag 21 november 2012 05:02 > > To: comm...@subversion.apache.org > > Subject: svn commit: r1411982 - in /subversion/branches/1.6.x: ./ STATUS > > subversion/libsvn_client/commit_util.c subversion/libsvn_fs_fs/fs_fs.c > > > > Author: svn-role > > Date: Wed Nov 21 04:01:41 2012 > > New Revision: 1411982 > > > > URL: http://svn.apache.org/viewvc?rev=1411982&view=rev > > Log: > > Reintegrate the 1.6.x-rep_write_cleanup branch: > > > > * r1403964, r1403982, r1410106, r1410203 > > Make fs_fs properly cleanup after a failed transmission of a > > representation. > > Justification: > > Read errors can create problems for users of the WANdisco replicator > > which does retry requests. Can result in garbage representations in > > the > > rev file. > > Notes: > > > > > Branch is required since our client code needs a small tweak to deal > > with pool lifetimes to make the fix work properly with ra_local. We'd > > made a similar change with wcng in 1.7 already. > > > What would be the effect of *not* patching the client? >
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. > What impact does this have on other users of the fs/repos apis? > > > In other words: Is this a breaking change that we shouldn't port back to 1.6 > clients and try to patch server only? > > Bert >
