RE: No-op changes no longer dumped by 'svnadmin dump' in 1.9

> -----Original Message-----
> From: Evgeny Kotkov [mailto:evgeny.kotkov_at_visualsvn.com]
> Sent: dinsdag 27 oktober 2015 14:38
> To: Bert Huijben <bert_at_qqmail.nl>
> Cc: Johan Corveleyn <jcorvel_at_gmail.com>; Stefan Fuhrmann
> <stefan.fuhrmann_at_wandisco.com>; Julian Foad
> <julianfoad_at_btopenworld.com>; dev <dev_at_subversion.apache.org>
> Subject: Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9

> In 1.9 we changed how svn_fs_contents_changed() works, added an errata,
> claimed that all of these distinctions are "false positives" [4], and switched
> all the calling sites to the new API that doesn't care about them. As one
> visible consequence, we no longer dump the changes that the original API
> was designed to preserve. And there could be more.

You are still focusing on the dump scenario.

I'm +1 on backporting that when documentation and regression tests are added.
(I think for that specific case the tests are done)

I'm just -0.9 on reverting the rest 'as it *may* have problems too'.

That is not a good enough reason for me to backport a 'revert to 1.8 style' thing. That part needs a better reason. The other behavior changes need their own tests, their own documentation and their own argumentation.

Backporting now and only then trying to determine where this affects behavior is the wrong order.

If somebody wants to backport more than the dump/load fix it should be for a good reason. And every part of a backport with such impact needs a reason.

We should find out where backporting the change affects behavior *now* and only backport after that. Not the other way around (Revert, release and only then review)

We can't undo the release of 1.9.0, 1.9.1 and 1.9.2... and going back to the old behavior is a huge change.

Yes, there are still more users that use 1.0-1.8.x, but that doesn't make the 1.9.0-1.9.2 behavior directly 'broken'... 1.8.x has different behavior, relying on unexpected/unintended features but for many users they are useful.

But I haven't seen a document update explaining why those errata you mentioned where *all false*.

I still see a reasoning for fixing 'dump'... and a patch (not even a nomination yet) for changing much more than dump.

If the errata were bad, I also miss the errata patch.

        Bert
Received on 2015-10-27 15:30:03 CET