> -----Original Message-----
> From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com]
> Sent: maandag 26 oktober 2015 17:45
> To: Bert Huijben <b...@qqmail.nl>; Stefan Fuhrmann
> <stefan.fuhrm...@wandisco.com>
> Cc: Johan Corveleyn <jcor...@gmail.com>; Julian Foad
> <julianf...@btopenworld.com>; dev <dev@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

Reply via email to