On Fri, Jun 20, 2014 at 12:55 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 20 June 2014 01:41, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
> wrote:
> > I just completed a patch that does exactly that.
> >
> > There is only one svnadmin test failing (trying to
> > read the l2p index in order to corrupt change lists
> > in a "controlled" way) and the svnfsfs tool can't
> > (re-)write index data atm. So it seems we get a
> > fix for the non-packed performance regression
> > before the end of this week.
> >
> > I just completed a patch that does exactly that.
> That sounds like a feasible idea but if we want to release 1.9 this
> year, we should revert the log adressing feature from the trunk and
> continue to redesign it in the feature branch.
>
The fixes are in /trunk now and release testing has not even started.
So, I don't see a reason for f7 to delay a 1.9.0 unless new, severe
issues will be found.
As to the complexity of the fixes, their total number of added and
changed lines is less than 450 and the logic is actually simpler now
as we don't have to make sure we can access 3 files that may get
deleted at any time anymore.
Every once in a while we port fixes larger than that into our *stable*
releases. For comparison, even your removal patch has 160 added
or modified lines.
> The log adressing feature is about 250kb of relatively complex code.
> It's about 20% of all FSFS codebase.
Yes, log addressing is a significant addition to the code base.
Considering that roughly 3x as much has been added between
1.1 and 1.8, this addition does not seem to be out of proportion.
> So it's not a good
> idea to perform significant rework and repository format change right
> before the release. I expect that this may delay the release for
> another 3-6 months at least.
>
What kind of rework are you thinking about? What would the
goal be?
-- Stefan^2.
Received on 2014-06-22 10:03:47 CEST