Ivan Zhakov <i...@visualsvn.com> writes: > On 22 May 2015 at 11:50, Philip Martin <philip.mar...@wandisco.com> wrote: >> >> Another approach would be to have a function to enable flushing directly >> on the stream created by svn_stream_from_aprfile2() without creating a >> new stream. This is probably the smallest/simplest patch. After >> reverting r1680819: >> > [...] > > This approach introduce dependency what kind of stream returned from > svn_stream_open_unique() which reduce advantage of using abstract > stream_t object.
It's a disadvantage but it also has the big benefit that it allows the flush to be applied to those wrappers. > Given all feedback I suggest do the following: > 1. Commit patch introducing svn_stream_from_aprfile3() with > FLUSH_ON_CLOSE argument, without deprecating > svn_stream_from_aprfile2(). > 2. I revert r1680819 > 3. Switch revprop change code to use svn_stream_from_aprfile3() with > FLUSH_ON_CLOSE=TRUE. > > Then I'll nominate alternative revisions from (1) and (3) to 1.9.x. That still leaves the problem of how to introduce a flush to something using open_writable or open_unique. Do those functions also get a FLUSH_ON_CLOSE flag to pass through the from_aprfile3? We have code that is using those functions and not flushing even though it probably should flush. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
