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: maandag 26 oktober 2015 17:45
> To: Bert Huijben <bert_at_qqmail.nl>; Stefan Fuhrmann
> <stefan.fuhrmann_at_wandisco.com>
> Cc: Johan Corveleyn <jcorvel_at_gmail.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

> This means that after r1572363 and r1573111, svn_ra_get_file_revs2() and
> svn_repos_get_file_revs2() were skipping some of the "interesting"
> revisions,
> according to the FS API defining the concept. Moreover, this behavior could
> be inconsistent even within a single function like svn_ra_get_file_revs2()
> that calls svn_ra_get_log2() for old servers, as get-log notices revisions
> with empty deltas.
>
> I think that it's another example of where r1572363 and r1573111 introduce
> an
> inconsistent and unwanted behavior change.

And 1.9.x assumes that the old behavior is a bug... and in many cases I agree.

This is exactly where the document Julian wrote comes in.

If we wanted 1.9.x to behave in all ways identical to 1.8.x, we wouldn't have created 1.9. We would have never released something different than the old thing. Stefan spend quite some time in improving things, and upto now most users agreed that this was an improvement. (The time to speak up was during the release candidates)

Every new feature or bugfix changes behavior.
Just 'thinking that this is another inconsistent behavior change' doesn't make a new argument on why this behavior change should be backported to 1.9.x.

I don't think reporting something as changed, when it is clearly not changed is a good thing.

We should decide when we want to see something as 'changed' and what definition of 'changed' should be used where.

Just going back to 1.8 is not the way to approach this.

That just changes one 'somehow broken implementation' (in one definition) with a 'somehow broken implementation' (with a different definition).

We should define what behavior we really want (where)... and document why we want that behavior there. Until then I don't think we should backport anything.

Both the 1.8.x behavior and the 1.9.x behavior are released... Going back to 1.8.x is not going to fix everybody's usecases.

        Bert
Received on 2015-10-26 18:16:55 CET