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

Re: Time to branch 1.9

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Fri, 7 Nov 2014 19:49:50 +0300

On 7 November 2014 17:57, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
> On Fri, Nov 7, 2014 at 2:07 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>
>> On 7 November 2014 03:00, Greg Stein <gstein_at_gmail.com> wrote:
>> > Forward progress is the goal. To *hold back* change, then you must veto.
>> >
>> I agree with that goal but not at the cost of possible massive data
>> corruptions in upgraded repositories. "There will always be bugs" ((c)
>> brane),
>> but we are currently *ripping out the revprop caching feature in the patch
>> release*! [4].
>
>
> Let's not repeat the revprop caching debacle. In Berlin this year,
> you told us that you had identified issues with it and decided to
> disable it in VisualSVN. Had you told us before 1.8, we might
> have found that the underlying infrastructure is too restrictive.

Are you trying to say that I did know the particular fatal issues
in the revprop caching before the 1.8 release? You are totally wrong,
if yes. Don't know if something like this is possible at Wandisco.
But this is absolutely not possible at VisualSVN.

Also, I'm not that smart, for sure. I just have had a suspicion
that something is internally wrong with that feature by looking
through your commits. That's why this feature is not enabled by
default in the product I'm responsible for. I didn't have strong
arguments against the revprop caching feature at that time.

> If not, you definitely would have found the init race under Windows;
> it's manifest in the Apache error logs. Everything that happened
> this summer wrt. to revprop caching could have been dealt with
> before 1.8.0.

That's great idea, thanks for investigation! But have you forgot
that revprop caching was actually disabled at the compilation time
because Windows atomics implementation were considered as
"inefficient" in 32-bit Windows builds?

As was accidently revealed unit tests for named atomics (and revprop
caching) were skipped under non-administrative account [1].

> Moving features behind one's personal maƱana horizon, be
> it "off by default" or "FSX", does nothing to aid that learning
> process.

And what you have learned from the "revprop caching debacle"? That
Ivan and other "template zombies" behaved in the wrong way and
didn't help you to success while you are saving this project from
unnecessary restrictions?

[1] http://svn.haxx.se/dev/archive-2014-09/0048.shtml

-- 
Ivan Zhakov
Received on 2014-11-07 17:51:28 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.