Johan Corveleyn <jcor...@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 callers. 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. Regards, Evgeny Kotkov
