On Mon, Jun 15, 2015 at 1:20 PM, Julian Foad <julianfoad_at_btopenworld.com>
wrote:
> My understanding of the situation is as follows. I'm not adding much
> to what Philip and Stefan have already diagnosed, I just want to say
> how I see it as well, and allow others to confirm it or correct me if
> necessary.
>
[snip insightful commentary that I agree with]
> Stefan Fuhrmann wrote:
> > Branko Čibej wrote:
> >> Philip Martin wrote:
> >>> Philip Martin writes:
> >>>> However the implementation of root_vtable_t.contents_changed() has
> >>>> changed in 1.9 and it no longer reports as many changes as it used to
> >>>> report so even replacing the _different() call with a _changed() call
> >>>> does not solve the problem. The only way I can see to fix the problem
> >>>> is to simply ignore/remove the call altogether and to hard-code
> >>>> contents_changed to TRUE.
>
> In other words, make svn_repos_get_file_revs2() give a text delta in
> all cases. If that makes the old blame code work again as well as it
> did before (I don't say 'correctly'), that is probably a good
> solution, as it doesn't sound like it would add much overhead or cause
> any other known problems. Of course that is bodging the behaviour to
> suit one particular caller that we know about. Other callers may exist
> that depend on some different behavioural details, but it's better to
> fix the breakage we know about.
>
Always sending a delta is reasonably safe - at least for blame.
In r1696478, I implemented a slightly more specific workaround:
It unconditionally sends the text delta whenever the path changes.
We are still deterministic and slightly more efficient than 1.8.
Future releases should have an option to either always send
deltas (empty or not) or to only send non-empty ones. Depending
on client capabilities, we can then pick either one.
-- Stefan^2.
Received on 2015-06-19 20:39:46 CEST