On Wed, Nov 27, 2013 at 12:19 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 25 November 2013 17:44, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
> wrote:
> > On Mon, Nov 25, 2013 at 1:29 PM, Philip Martin <philip_at_codematters.co.uk
> >
> > wrote:
> >>
> >> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
> >>
> >> > On Tue, Sep 24, 2013 at 6:51 PM, Ivan Zhakov <ivan_at_visualsvn.com>
> wrote:
> >> >
> >> >> On 23 August 2013 03:21, Stefan Fuhrmann <
> stefan.fuhrmann_at_wandisco.com>
> >> >> wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > As of r1516665, work on this branch has been completed.
> >> >> > Please review. See the BRANCH-README for the list of
> >> >> > major changes.
> >> >> >
> >> >> > If there are no objections, I will merge the code in the week
> >> >> > of Sep 23th.
> >> >> >
> >> >> Hi Stefan,
> >> >>
> >> >> I have looked through the code but I'm not ready to put my +1 on it.
> I
> >> >> think this branch is a good candidate for the "three +1" policy
> >> >> discused some time ago.
> >> >>
> >> >
> >> > Would you vote +1 under the 3-vote policy ("seems o.k. but more
> >> > independent review should take place")?
> >>
> >> I've been reviewing this branch and I am now happy for it to be merged
> >> to trunk.
> >
> >
> > 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.
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. (*)
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,
So, this is what I will do. I will merge the branch in time
for the alpha release but keep the source branch around.
If we discover severe problems with the code we can
undo the change on /trunk at any point before going beta.
This is the whole point of using a VCS, right?
-- Stefan^2.
(*) See, speed *does* matter.
Received on 2013-11-28 07:23:33 CET