RE: No-op changes no longer dumped by 'svnadmin dump' in 1.9
Date: Wed, 21 Oct 2015 16:18:03 +0200
The 'revert' to something like '1.8' also introduces most changes on 1.9.x behavior. If you look at it that way, you have more to review, the more you revert to 1.8.
I'm still not convinced that the 1.8 behavior is really the behavior we want *everywhere*. Julian's great document outlines the different ways we look at this in different scenarios.
Noting everything as a change even if there is no actual delta... still looks like a bug we should fix (and we did) instead of something that we should restore.
For the reasoning on why:
Blame with mergeinfo is just a hack, which has all kinds of assumptions on how closely all merged branches are related. We simply don't store the information to really obtain where the change originated*. The way this code (build as a summer of code project if I remember correct) assumed that every revision was reported as interesting is just one of the many limitations.
Keeping this broken code working is not a goal by itself, that should force us to keep our apis inefficient.
* I think we once (far before 1.5) had a branch that started to really store what was needed here. Perhaps Julian's current work will improve things later on.
Sent from Mail for Windows 10
From: Evgeny Kotkov
Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
> Could you at least use the new API in svn_repos__compare_files instead
Speaking of /branches/1.9.x, I would like to nominate this change as is.
As for /trunk, I think that we could do that, so I sketched this option in
This is an archived mail posted to the Subversion Dev mailing list.