On Fri, Nov 29, 2013 at 5:29 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 28 November 2013 10:22, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
> wrote:
> [...]
>
> >> >
> >> > Thanks a lot, Philip!
> >> > I plan on merging the branch later this week (Friday-ish).
> >> >
> >> Well, I still think that log-addressing branch should *NOT* be merged
> >> and all FS _performance_ and format changes should be implemented in
> >> FSX.
> >
> >
> > One more thing. Are you aware that for all we know today,
> > move support requires log scans? Probably even for updates.
> > This is the very operation that benefits most from format 7.
> > And so do merges.
> What I'm worry about is bottom-up design approach: we're going to
> release fsfs 7 and then someday use it to solve moves and merges.
>
You are confusing two independent topics:
(1) Storing "native" move information in the FS layer.
There is some experimental code for this on trunk
that may or may not help people developing the
move merge feature. We can decide to remove or
disable it at any point before release.
(2) Ability to deliver the amount of log information
required for move-aware updates and merges with
reasonable speed. This is what FSFS format 7 provides.
So, your "bottom-up" argument is false.
> > I think I fully understand your position. Your concerns are:
> >
> > * Minimize code churn (= potential destabilization) in FSFS
> > * Protect users against repository corruption.
> > * Implement features that users crave for, like full move support.
> >
> > The latter two effectively hinge upon format 7. So, let's make
> > the first point as little an issue as we can (see below).
> >
>
> >> My primary concern is that currently FSFS supports reading and writing
> >> all FSFS formats. And there are more than 6 formats now, because they
> >> can differ of how repositories were upgraded. This makes code very
> >> complicated, because it should handle all different combinations of
> >> formats/upgrades.
> >
> >
> > Well, the obvious way to address this concern is to extend
> > testing. You may not be aware that running tests on /trunk
> > takes only 2:00 min in debug and 1:50 in release. Running
> > the test suite [fsfs +svn x all minor server versions] is not
> > a problem any longer. (*)
> >
> Test suite execution time is developers problem, not users.
>
Again, you are missing the point. You are saying that there
are lots of possible configurations and various combinations.
I'm saying that we *are* actually able to test many variants.
One simply needs to update their overall test script.
> > It should also be no problem to test repository upgrades:
> > A new option could tell the tests to create the repo in whatever
> > old format was selected and then do an 'svnadmin upgrade'
> > before running the remainder of the test. Given your observation
> > that FSFS format dependencies have already caused trouble
> > in the past, adding these kinds of tests is a good idea even
> > without format 7,
> Let's do proposed test suite improvements first, instead of pushing
> changes to trunk.
Alright. I think I can do these additions by Sunday night.
Going to merge right after that.
> We also need setup buildbots to test all FSFS
> formats to prevent problems like we got with revprop packing stuff.
>
It is certainly a good idea to have different repository formats
in our build bots to increase code coverage. But I don't see
that holding off an alpha release.
-- Stefan^2.
Received on 2013-11-30 08:49:08 CET