Re: svn commit: r1680819 - /subversion/trunk/subversion/libsvn_fs_fs/revprops.c

Ivan Zhakov <ivan_at_visualsvn.com> writes:

> On 22 May 2015 at 11:50, Philip Martin <philip.martin_at_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*