On Fri, Nov 7, 2014 at 5:49 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> 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 my memory fails me here, then I sincerely want to apologize.
This is what I remember: In a group, we were just discussing
the premisses of f7 at that time, like "reasonable server config".
That lead you to the statement that you had identified "alignment
issues" with revprop caching and ultimately disabled it in VisualSVN.
I was baffled because first, the "alignment" was most certainly
correct (assuming you referred to SHM) and secondly this has
been the first time I became aware of any issue that would
make the feature generally unusable. Asking for more details,
you said you couln't exactly remember - which is perfectly fine;
it only means that it may have been a completely different problem
than alignment.
Now assume you had been as persistent with it as you are with
f7, it might still have been a painful process to work it out.
But the result might have been something like revprop-caching-ng
released with 1.8 or more likely 1.9.
And that is the whole point I want to make here. Bringing up
tangible issues will help us maturing the code or even realizing
that, in fact, it does not work for FSFS because of XY and Z.
FSX, for instance, can then try of avoid them. Even not finding
issues, after trying hard, helps creating a deeper understanding
of how things work.
Also, I want to say that I *am* responsible for the debacle as
a whole. For reasons that are beyond me, I did not mention the
limitations in the release notes (mentioned them to various
people at different times but not there). That alone would probably
have created enough discussion to prevent the situation we
had in summer this year.
> 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].
>
Fair enough. You used pre Win5.02 settings and did not
see in your tests that revprop caching was effectively "off".
> > 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?
>
You've got me completely wrong there, I was simply referring to
a concept outlined in the book that I wasn't sure you know (couldn't
find a more immediate reference). I should have explained that
concept in more detail - so here go.
Everyone has a personal "mañana horizon", e.g. "2 weeks",
which depends on the issue at hand, stress level etc. Everything
beyond that point is perceived as "sometime in the future" and
any problem before that point tends to trump possibly more important
issues beyond it. A typical example is the firm project deadline
5 years, 3 months and 17 days into the future. Many people will
have a hard time truly committing themselves to that goal.
In relation to repository features, simply delaying them does not
reduce any of the risks involved with them. Code does not mature
if it does not get reviewed, tested and eventually used in production.
Delaying things may *feel* like a solution even though it often is not.
And that is exactly the effect what the "mañana horizon" describes.
BTW, the patterns described in the book may have catchy names
but they are often not, by themselves, "good" or "bad". They occur
and recognizing them can prevent talking past one another. One
of the few books I'd really recommend reading to people in the
tech industry.
-- Stefan^2.
Received on 2014-11-07 19:01:04 CET