Johan Corveleyn <jcorvel_at_gmail.com> writes:
> I don't know if a full revert, or a forward-working fix is the best
> course of action. The immediate concern for me is fixing the
> regression of losing no-op change information in dumps. Perhaps if
> stefan2's work can be fitted in the larger picture of a design such as
> Julian's (and then fix the bugs from that perspective), that might be
> the best way forward. Or perhaps this is too risky to do in a short
> time frame (since we already have the bug in released versions), and
> it's best to rollback and perform the "rework" with a proper design
> for 1.10 (so there is more time to stabilize design and
> implementation)? Dunno.
> Would the rollback reintroduce old bugs or unpredictable behavior that
> we know of?
As far as I know, there are no bugs associated with the old code.
On the contrary, the new code has a history of problems. The corresponding
changesets, r1572363 and r1573111, update every single caller and state that
all of them would benefit from the new strict behavior. As we now know, at
least two of them don't, and I also do not think that we can foresee the
consequences from changing the behavior of other four, because this low
level change propagates to higher level public functions used by many other
Irrespectively of what we plan for 1.10, there's a problem in a 1.9 that we
need to solve. The associated issues are hard to diagnose and hard to stumble
upon, and I don't think that fixing them one by one as we become aware of
their existence is a way to go, as opposed to just restoring the stable
behavior. That's why I would like to commit the patch that does that, and
backport it to /branches/1.9.x — in order to fix the regression in svnadmin
dump, and to be safe against the unknown amount of similar problems.
The new API would still be there and available for us, in case we require it
somewhere in the future.
Received on 2015-10-15 15:00:20 CEST