[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: Paul Burba <ptburba_at_gmail.com>
Date: Mon, 8 Aug 2011 13:17:03 -0400

On Mon, Aug 8, 2011 at 1:14 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> On Mon, 2011-08-08 at 13:11 -0400, Mark Phippard wrote:
>> 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.
>
> I'm not looking into it.  Paul, it would be great if you could.

Already on it, sorry, had a draft ready to send this morning that I
was looking into it...just forgot to hit "send" :-\
> - Julian
>
>
>
Received on 2011-08-08 19:17:34 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.