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

Re: svn commit: r1698359 - in /subversion/trunk/subversion: include/svn_io.h libsvn_subr/stream.c svnadmin/svnadmin.c svnfsfs/load-index-cmd.c tests/libsvn_subr/stream-test.c

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 2 Sep 2015 16:01:08 +0200

On Wed, Sep 2, 2015 at 2:43 PM, Evgeny Kotkov
<evgeny.kotkov_at_visualsvn.com> wrote:
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>>> Given the above, I am -1 on this optimization for svnadmin load-revprops
>>> that was implemented in r1698359 and r1700305. Please revert these
>>> changes.
>> Thinking about alternative solutions I found that simply having a buffering
>> wrapper without mark support would still eliminate the OS overhead and parts
>> of the internal overhead. That would address all the points you have made
>> above while still providing a decent improvement.
>> IOW, revert r1700305 and rework / reduce / simplify the code changed
>> by r1698359.
> I stated my veto and provided the justification that covers both r1700305
> and r1698359. So, could you please revert both of them? Reworking and
> adding changes on top of it is going to increase the mess and will be harder
> to review.

ISTR that in this community we try to treat a veto as a signal that
further discussion is needed, or that more work is needed to resolve
the question / issue. You may ask / suggest a revert if you think
that's best, but it's mainly up for discussion how to best resolve
things (and other avenues, such as further commits, may also resolve
the issue).

Of course, in some circumstances there is more pressure to revert
quickly (e.g. when the build is broken, or other developer's work is
blocked for other reasons, or ...). But usually we try to work our way
towards consensus without "forcing" a revert.

On the other hand, it might have been better for Stefan to wait for
your reaction first, and discuss the issue and a possible solution,
before making further changes ...
It's not like this is such an urgent matter that it cannot wait for a
couple of days ...

Just my 2 cents,

Received on 2015-09-02 16:01:41 CEST

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