I'm not in the mood to split hairs right now (those who need to know why).
I'll just say that I haven't had time to review the revprop cache branch,
so obviously I can neither approve nor veto it. The general approach was
discussed at the hackathon in Sheffield, and I did agree with that.
Ivan, since you called me out about techical grounds, I'll just repeat what
I already said: if you have specific objections, point them out. Saying "I
object!" is just not good enough.
-- Brane
On 8 Sep 2014 18:24, "Ivan Zhakov" <i...@visualsvn.com> wrote:
> > (FWIW, maintaining the remove-log-addressing branch doesn't count, and
> > frankly I have a hard time imagining how that branch could be less buggy
> > than trunk, given that it's received far less attention and testing.)
> As you should know, current FSFS code on trunk is like this:
> if (log_addressing_enabled(rev))
> {
> do_one();
> }
> else
> {
> do_else();
> }
>
> And this covers *all* cases, because FSFS code supports reading and
> *writing* all previous FSFS formats. I've just removed do_one() calls on
> remove-log-addressing branch. How this could be more buggy?? Please
> provide more details about this point.
>
> > You must have forgotten the history of ra_serf: almost nobody used it
> > until we made it the default and only option, and so we only started
> > getting useful feedback after the 1.8.0 release.
>
> We release features not just to get a 'useful feedback' from the users.
> There was a lot of work to prepare ra_serf to be the default option. I
> guess
> we would have a different kind of feedback if this work have not been done.
>
> >> Moreover, we have discussed
> >> this on Berlin 2013 hackathon [1]:
> >> [[[
> >> stefan2 expressed that while he is confident that FSFSv7 is solid code,
> >> it's also quite critical and could easily take a year or more to fully
> >> stabilize. Attendees felt that perhaps it would be best to introduce
> FSFSv7
> >> as a new, experimental fs-type. Stefan said he had been thinking
> >> about the same thing himself, even considering a different name for
> >> his implementation.
> >> ]]]
> > Yup, we did; more than a year ago. A lot has changed since then.
> What exactly have changed and where it was discussed?
>
> > I'll even go as far as to suspect that you're not aware there's no
> revprop
> > caching on trunk right now.
>
> Should I suspect that you are saying this to make it seem that I don't have
> any technical ground behind my position?
>
> As I said elsethread, I routinely read everyone's commits to Subversion
> codebase (with different level of attention, of course). Moreover, both
> problems that caused to disable revprop caching on trunk were initially
> found by two of my colleagues. So, despite the fact that I've been on
> vacation when r1619774 was committed, I obviously know the story.
>
> Also, I do not see yours '+1' or other kind of positive feedback regarding
> the revprop-caching-ng branch.
>
> Have you got a chance to review the revprop-caching-ng branch?
>
> Do you agree with all the significant technical solutions adopted in
> this branch?
>
>
> --
> Ivan Zhakov
>
