'svn log -g' weirdness.

Paul committed a merge of r31927 from trunk to his 1.5.x-issue3067 branch in
r32122. But 'svn log -g' doesn't seem to notice:

    $ svn log -gv -r32122 http://svn.collab.net/repos/svn
    ------------------------------------------------------------------------
    r32122 | pburba | 2008-07-14 21:25:56 -0400 (Mon, 14 Jul 2008) | 10 lines
    Changed paths:
       M /branches/1.5.x-issue3067
       M /branches/1.5.x-issue3067/CHANGES
       M /branches/1.5.x-issue3067/COMMITTERS
       M /branches/1.5.x-issue3067/subversion/bindings/swig
       M /branches/1.5.x-issue3067/subversion/libsvn_client/merge.c
       M /branches/1.5.x-issue3067/subversion/tests/cmdline/merge_tests.py

    On the 1.5.x-issue3067 backport branch, merge r31927 from trunk.

    * subversion/tests/cmdline/merge_tests.py
    * subversion/libsvn_client/merge.c
      Clean merge.

    * src-branch-3067, CHANGES, COMMITTERS, subversion/bindings/swig:
      Mergeinfo updates.

    ------------------------------------------------------------------------
    $ svn diff -c32122 http://svn.collab.net/repos/svn | grep " Merged"
       Merged /trunk/COMMITTERS:r31927
       Merged /trunk/subversion/bindings/swig:r31927
       Merged /trunk/CHANGES:r31927
       Merged /trunk:r31927
    $

Any ideas why? Now, I already know that our current 'log -g' mergeinfo
delta calculation is broken (see issue #3235), but even with that brokenness
I wouldn't have expected this result. Anyway, not sure why I'm mailing the
list about this. I'm completely rewriting the way we detect mergeinfo
changes in the log -g codebase (originally for performance, but I think I
can achieve greater correctness, too), so it may not be in anyone's interest
to investigate this themselves. I guess I just want folks to be able aware
the extent of the problem in case users come asking why 'log -g' doesn't
always work as expected.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand