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
