On Mon, Jun 22, 2015 at 3:42 PM, Bert Huijben <b...@qqmail.nl> wrote:
> > > > -----Original Message----- > > From: stef...@apache.org [mailto:stef...@apache.org] > > Sent: vrijdag 19 juni 2015 20:29 > > To: comm...@subversion.apache.org > > Subject: svn commit: r1686478 - in /subversion/trunk/subversion: > > libsvn_repos/rev_hunt.c tests/libsvn_client/mtcc-test.c > > > > Author: stefan2 > > Date: Fri Jun 19 18:29:01 2015 > > New Revision: 1686478 > > > > URL: http://svn.apache.org/r1686478 > > Log: > > Workaround for 'svn blame' -g with old clients. > > > > Old clients rely on receiving a callback whenever the path changes, e.g. > > when switching from one branch to another. So, for now, we > unconditionally > > send a text delta in that case. Future releases should make that > backward > > compatibility behavior an option that will be controlled be e.g. client > > capabilities. > > > > Found by: philipm > > > > * subversion/libsvn_repos/rev_hunt.c > > (send_path_revision): Always send a text delta when the path changes. > > > > * subversion/tests/libsvn_client/mtcc-test.c > > (handle_rev): Update the expectations. > > > > Modified: > > subversion/trunk/subversion/libsvn_repos/rev_hunt.c > > subversion/trunk/subversion/tests/libsvn_client/mtcc-test.c > > > [snip] > Is this really always when ther path changed, or only when the path > changed *and* we are looking at a -g blame? > > The fact that we see a path change might be a quite visible side effect on > a -g blame (where different branches have different paths), but it can also > happen on a rename (without actual change to the file) on a non -g blame. > I now tested it with renames, modifying renames and double renames (clean rename in rN, modifying rename in rN+1). Normal 1.8.x blame seems to work correctly against 1.8 and 1.9 servers without the patch. > If this fix is only relevant to -g blames we shouldn't apply it to other > blame invocations. > r1686888 now restricts the hack to -g mode. -- Stefan^2.
