On Mon, Jun 22, 2015 at 3:42 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
> > Sent: vrijdag 19 juni 2015 20:29
> > To: commits_at_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.
Received on 2015-06-22 18:27:26 CEST