On 01/24/2017 12:01 PM, Daniel Shahaf wrote:
> 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.
As a bug report alone, this one seems pretty easy: Closed/INVALID.
Dumpfile headers were never promised in a particular order, therefore
that their order should differ in one version than in another is an
interesting factoid, but not actionable *as a defect*. I think it
unwise to introduce an option to dictate that new code should try to
adhere to an old promise that wasn't.
Now, it's completely reasonable to introduce into the current release a
promise regarding future header ordering, though. And it is completely
reasonable to backport an enforcement of that ordering (minus its
attached promise?) to older releases for the benefit of users that
care. And it may very well be that "the 1.8 ordering" is the very
ordering you'd settle on, but perhaps not. But to even get here, I
think folks have to decide if this is, in fact, a promise that
Subversion wants to make. And if so, how universally? Does this order
apply to svndumpfilter and svnrdump, too?
In all these scenarios though, nothing can be done about released code
save, as you suggest, Daniel, to introduce some external comparator.
-- Mike
Received on 2017-01-24 18:37:54 CET