Julian Foad wrote on Tue, Jan 24, 2017 at 09:51:52 +0000:
> Luke Perkins wrote:
> >I have defined a new switch for “svnadmin dump –pre-1.8-dump” to
> >activate the old node key order. I did my best to try to keep the
> >original authors style. Is this an acceptable switch name?
> >
> >A new parameter to the primary function, “svn_repos_dump_fs4”, called
> >“svn_boolean_t pre_1_8_dump,”. I have search the source code and
> >I think I have all of the function calls covered. Are there any other
> >considerations?
>
> Every new option we add carries new costs with it -- maintenance,
> documentation, user education, more variations to test, etc.
>
> I think there is no significant reason to disable the ordering. Of course
> compatibility is always a concern, and we don't want to fix one use case
> while breaking another. I suppose it could be that the supposedly unstable
> order has actually been coming out stable for some people, in which case
> they would potentially benefit by leaving it is as it -- but that's being
> too "tricky" -- we should keep it simple by not adding an option.
>
> Do you have any particular reason why you think the option is necessary?
The bug is about 1.9 using a different order to 1.8. If we make
svnadmin use the 1.8 unconditionally, then 1.9 will use a different
order to 1.10, which essentially recreates the bug for other users.
That is: the option serves to allow admins to choose which of the two
orders to be consistent with, 1.8 or 1.9.
An alternative to having this option would be a dumpfile comparator that
ignores header order differences.
> >What is the verification procedure for implementing this change?
>
> Running the regression test suite with the (rather hidden)
> "--dump-load-cross-check" option enabled, plus feedback from yourself and
> one or two others that it "works for you".
I think Luke was asking about whether a unit test is required. I'll
leave it to you guys to decide that, but just point out for Luke that
svnadmin_tests.py would be where such a test would live.
Cheers,
Daniel
Received on 2017-01-24 18:04:47 CET