You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2011/08/05 23:20:40 UTC
JavaHL bug in 1.7 retrieving mergeinfo
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.
NOTE: in my test you get no results back when it fails. However, when the
same test is run against the root of our tree you do get results, you just
do not get the right results.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: JavaHL bug in 1.7 retrieving mergeinfo
Posted by Paul Burba <pt...@gmail.com>.
On Mon, Aug 8, 2011 at 1:14 PM, Julian Foad <ju...@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 <ju...@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.
Already on it, sorry, had a draft ready to send this morning that I
was looking into it...just forgot to hit "send" :-\
> - Julian
>
>
>
Re: JavaHL bug in 1.7 retrieving mergeinfo
Posted by Julian Foad <ju...@wandisco.com>.
On Mon, 2011-08-08 at 13:11 -0400, Mark Phippard wrote:
> On Mon, Aug 8, 2011 at 5:13 AM, Julian Foad <ju...@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
Re: JavaHL bug in 1.7 retrieving mergeinfo
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 8, 2011 at 5:13 AM, Julian Foad <ju...@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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: JavaHL bug in 1.7 retrieving mergeinfo
Posted by Julian Foad <ju...@wandisco.com>.
On Mon, 2011-08-08 at 11:22 +0200, Miha Vitorovic wrote:
> On 8.8.2011 11:13, Julian Foad wrote:
> > The other day I noticed that the 'svn mergeinfo' command passes
> > changed the parameter to FALSE and found that the result was actually
> > slower. Looking further now, I see that the result is different.
> >
> > with svn_client_mergeinfo_log(discover_changed_paths=TRUE):
> > with svn_client_mergeinfo_log(discover_changed_paths=TRUE):
>
> Cough...
Oops. The second one (the one that gave more results) was meant to say
'with discover_changed_paths=FALSE'.
- Julian
Re: JavaHL bug in 1.7 retrieving mergeinfo
Posted by Miha Vitorovic <mi...@gmail.com>.
On 8.8.2011 11:13, Julian Foad wrote:
> The other day I noticed that the 'svn mergeinfo' command passes
> changed the parameter to FALSE and found that the result was actually
> slower. Looking further now, I see that the result is different.
>
> with svn_client_mergeinfo_log(discover_changed_paths=TRUE):
> with svn_client_mergeinfo_log(discover_changed_paths=TRUE):
Cough...
Br, Miha
Re: JavaHL bug in 1.7 retrieving mergeinfo
Posted by Julian Foad <ju...@wandisco.com>.
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
- Julian
Re: JavaHL bug in 1.7 retrieving mergeinfo
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Aug 5, 2011 at 5:20 PM, Mark Phippard <ma...@gmail.com> 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.
>
> NOTE: in my test you get no results back when it fails. However, when the
> same test is run against the root of our tree you do get results, you just
> do not get the right results.
>
I have updated the attached test to make the failure scenario a little more
clear to someone that runs this. I also future-proofed it a bit in case the
items it is checking for are eventually merged (in which case the test would
not be valid any more).
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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/