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].
But the point is that Brane is right in saying that the assumed
existence of bugs does not justify cancelling the development
of new features. Any "technically small" bug can render SVN
next to useless - temporarily or permanently. We have seen
them in the working copy, the communication layer and the
repository. People how cannot afford the risk must live with the
known risks and problems and not upgrade to a newer SVN.
The way to prevent those situations is to think of ways to break
the code. Basically, blackbox and whitebox testing. If we don't
keep looking for bugs, our understanding of the key issues
underneath them cannot grow. Moving features behind one's
personal mañana horizon [1], be it "off by default" or "FSX",
does nothing to aid that learning process. In turn, it does not
solve the problems.
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.
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.
My side of the bargain has been trying to think of unnecessary
restrictions that FSFSv7 might have and then to fix them. It
started with performance in "unmanaged" setups, continued
with support for heterogeneous clusters and currently ended
with defined behaviour after hot upgrade. I also "shot bullets"
at repositories to see whether random corruption could sneak
past our consistency checks. And I will continue testing more
and more scenarios.
-- Stefan^2.
[1]
http://www.amazon.com/Adrenaline-Junkies-Template-Zombies-Understanding/dp/0932633676
Received on 2014-11-07 15:58:49 CET