On Mon, 2011-08-08 at 13:11 -0400, Mark Phippard wrote: > On Mon, Aug 8, 2011 at 5:13 AM, Julian Foad <julian.f...@wandisco.com> > wrote: > On Sat, 2011-08-06, Mark Phippard wrote: > > The attached Java program shows a bug in 1.7 when > calling the > > getMergeinfoLog API. If the discoverChangedPaths > boolean is > > set to true we do not get back the expected > results. When it > > is false, the API works properly. > > [...] > > It still boils down to the discoverChangedPaths boolean > breaks the > > functionality. I have traced the source code into > svn_client and it > > all seems OK to me. There is nothing obvious about this > particular > > parameter that seems wrong. Maybe the code that calls > svn_client_log5 > > is not properly setup to handle the additional callbacks for > the > > changed paths? That is all I can think of. > > > The other day I noticed that the 'svn mergeinfo' command > passes > 'discover_changed_paths = TRUE' to svn_client_mergeinfo_log(), > although > it doesn't need this information. Expecting to improve > performance, I > changed the parameter to FALSE and found that the result was > actually > slower. Looking further now, I see that the result is > different. > > Example: svn mergeinfo --show-revs=eligible > ^/subversion/branches/1.7.x@1154862 ^/subversion/trunk@1154862 > > with svn_client_mergeinfo_log(discover_changed_paths=TRUE): > r1150779 > r1151037 > ... > r1154720 > r1154734 > > with svn_client_mergeinfo_log(discover_changed_paths=TRUE): > r1148717 > r1148828 > ... > r1150779 > r1151037 > ... > r1154720 > r1154734 > > > OK, so that confirms the problem is in the core svn_client API. Are > you by chance looking into this? If not, maybe Paul Burba can take a > look at it.
I'm not looking into it. Paul, it would be great if you could. - Julian
