[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: JavaHL bug in 1.7 retrieving mergeinfo

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 8 Aug 2011 13:11:29 -0400

On Mon, Aug 8, 2011 at 5:13 AM, Julian Foad <julian.foad_at_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_at_1154862 ^/subversion/trunk_at_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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-08 19:11:58 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.