You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Joe Swatosh <jo...@gmail.com> on 2009/10/21 05:36:14 UTC
State of the bindings buildbot
Hi All,
The Ruby bindings are now passing all tests, except for
test_adm_ensure which is being flunked pending some discussion about
changes to svn_wc_ensure_adm4. Specifically it sounds like there are
a couple arguments that may no longer accept nulls.
There is a Java error and failure also. I apologize for the long time
that the bindings buildbot has been failing due to Ruby, and masking
other potential problems. Now that the Ruby bindings are close to
passing again, I hope that the Java bindings will get fixed soon, too.
Thanks!
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409638
Re: State of the bindings buildbot
Posted by Paul Burba <pt...@gmail.com>.
On Wed, Oct 21, 2009 at 10:47 AM, Hyrum K. Wright <hy...@hyrumwright.org> wrote:
> On Oct 21, 2009, at 9:38 AM, Mark Phippard wrote:
>
>> On Wed, Oct 21, 2009 at 10:34 AM, Joe Swatosh
>> <jo...@gmail.com> wrote:
>>> On Wed, Oct 21, 2009 at 6:26 AM, Mark Phippard <ma...@gmail.com>
>>> wrote:
>>>> On Wed, Oct 21, 2009 at 1:36 AM, Joe Swatosh
>>>> <jo...@gmail.com> wrote:
>>>>
>>>>> There is a Java error and failure also. I apologize for the long
>>>>> time
>>>>> that the bindings buildbot has been failing due to Ruby, and
>>>>> masking
>>>>> other potential problems. Now that the Ruby bindings are close to
>>>>> passing again, I hope that the Java bindings will get fixed soon,
>>>>> too.
>>>>
>>>
>>>> The failure is relatively new, and involves the diff tests. There
>>>> is
>>>> work going on in this area and there have been failing tests in the
>>>> main test suite, so I suspect these are related. I have been
>>>> holding
>>>> off looking at it until that work seems done, as I kind of expected
>>>> the test to start working again. Based on the assertion failure, it
>>> I know what you mean. I was just getting excited to see a green
>>> build,
>>> after the Ruby bindings being the bad actor for such a long time. I
>>> should have realized you were tracking....
>>
>> I was able to find the problem in the library and fixed it in r40148,
>> so the prodding was worthwhile!
>>
>> I can fix the other JavaHL test by using --accept=theirs-conflict
>> instead of theirs-full. For the purposes of the test I was doing it
>> does not change anything. I worry that I am just covering up a real
>> error that needs to be fixed though. I am not clear as to why the
>> main tests are Green with this problem still in place. Every command
>> line user will see it when they use that accept option.
>
> Is there a commandline test for it? If not, could we write one? If
> so, I'd be interested to see why it isn't failing, or why it is marked
> XFail().
>
Hey All,
There are passing tests for svn [resolve | update] --accept [base |
theirs-full] but there is nothing for merge. I added an issue,
http://subversion.tigris.org/issues/show_bug.cgi?id=3514, and a test
in r40206.
The --accept base option has never worked, at least in release; I
checked back to 1.5.0 and it segfaults. I guess the lack of test and
lack of popularity* of --accept base have kept this hidden for some
time.
*I see no mention of this problem on the users list.
--accept theirs-full started segfaulting (and the JavaHL test with it)
in Hyrum's r39114:
[[[
Instead of conditionally creating a temporary file inside an access baton's
temp area, just use the system temp area.
* subversion/libsvn_client/repos_diff.c
(create_empty_file): Remove.
(get_empty_file, apply_textdelta): Directly get a temp file in the
system temporary area.
]]]
Stefan replaced the segfault with a slightly more palatable error in r39418:
[[[
Raise an error in loggy_path() when given paths that are not in the WC,
rather than letting the code segfault. (Absolute paths in /tmp seem to be
coming from merge operations). Callers of loggy_path() are not prepared
to handle a NULL return anyway. Even though this stuff is going away,
it is crashing midway through the javahl tests. With this change,
the javahl tests complete, getting 1 error and 2 failures.
* subversion/libsvn_wc/log.c
(loggy_path): Return an error if PATH is not a child of ADM_ABSPATH.
The new behaviour is consistent with loggy_paths()'s docstring,
which says that "PATH must not be outside that directory."
Patch by: Dave Brown <da...@wandisco.com>
(patch and log message slightly tweaked by me)
]]]
Stefan, I assume you mean by "Even though this stuff is going away",
that with the ultimate completion of wc-ng, all the loggy code will be
gone and this should just starting working at some point before then,
right?
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410755
Re: State of the bindings buildbot
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 21, 2009 at 10:47 AM, Hyrum K. Wright
>
> Is there a commandline test for it? If not, could we write one? If so, I'd
> be interested to see why it isn't failing, or why it is marked XFail().
Paul said he will look at adding one. I just fixed the JavaHL test so
currently there is no test that shows this problem exists.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409806
Re: State of the bindings buildbot
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Oct 21, 2009, at 9:38 AM, Mark Phippard wrote:
> On Wed, Oct 21, 2009 at 10:34 AM, Joe Swatosh
> <jo...@gmail.com> wrote:
>> On Wed, Oct 21, 2009 at 6:26 AM, Mark Phippard <ma...@gmail.com>
>> wrote:
>>> On Wed, Oct 21, 2009 at 1:36 AM, Joe Swatosh
>>> <jo...@gmail.com> wrote:
>>>
>>>> There is a Java error and failure also. I apologize for the long
>>>> time
>>>> that the bindings buildbot has been failing due to Ruby, and
>>>> masking
>>>> other potential problems. Now that the Ruby bindings are close to
>>>> passing again, I hope that the Java bindings will get fixed soon,
>>>> too.
>>>
>>
>>> The failure is relatively new, and involves the diff tests. There
>>> is
>>> work going on in this area and there have been failing tests in the
>>> main test suite, so I suspect these are related. I have been
>>> holding
>>> off looking at it until that work seems done, as I kind of expected
>>> the test to start working again. Based on the assertion failure, it
>>
>>>
>>
>> I know what you mean. I was just getting excited to see a green
>> build,
>> after the Ruby bindings being the bad actor for such a long time. I
>> should have realized you were tracking....
>
> I was able to find the problem in the library and fixed it in r40148,
> so the prodding was worthwhile!
>
> I can fix the other JavaHL test by using --accept=theirs-conflict
> instead of theirs-full. For the purposes of the test I was doing it
> does not change anything. I worry that I am just covering up a real
> error that needs to be fixed though. I am not clear as to why the
> main tests are Green with this problem still in place. Every command
> line user will see it when they use that accept option.
Is there a commandline test for it? If not, could we write one? If
so, I'd be interested to see why it isn't failing, or why it is marked
XFail().
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409804
Re: State of the bindings buildbot
Posted by Joe Swatosh <jo...@gmail.com>.
On Wed, Oct 21, 2009 at 7:38 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, Oct 21, 2009 at 10:34 AM, Joe Swatosh <jo...@gmail.com> wrote:
>> On Wed, Oct 21, 2009 at 6:26 AM, Mark Phippard <ma...@gmail.com> wrote:
>>> On Wed, Oct 21, 2009 at 1:36 AM, Joe Swatosh <jo...@gmail.com> wrote:
>>>
>>>> There is a Java error and failure also. I apologize for the long time
>
> I was able to find the problem in the library and fixed it in r40148,
> so the prodding was worthwhile!
>
Awesome!
> I can fix the other JavaHL test by using --accept=theirs-conflict
> instead of theirs-full. For the purposes of the test I was doing it
> does not change anything. I worry that I am just covering up a real
> error that needs to be fixed though. I am not clear as to why the
> main tests are Green with this problem still in place. Every command
> line user will see it when they use that accept option.
>
I wonder the same thing about the svn_wc_ensure_adm4 taking nulls.
Bert mentioned that the chatter on irc has been to just disallow them,
so I'll probably modify the test tonight. But it is off to work now.
Thanks for looking more closely, it'll be nice to have this green soon.
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409808
Re: State of the bindings buildbot
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 21, 2009 at 10:34 AM, Joe Swatosh <jo...@gmail.com> wrote:
> On Wed, Oct 21, 2009 at 6:26 AM, Mark Phippard <ma...@gmail.com> wrote:
>> On Wed, Oct 21, 2009 at 1:36 AM, Joe Swatosh <jo...@gmail.com> wrote:
>>
>>> There is a Java error and failure also. I apologize for the long time
>>> that the bindings buildbot has been failing due to Ruby, and masking
>>> other potential problems. Now that the Ruby bindings are close to
>>> passing again, I hope that the Java bindings will get fixed soon, too.
>>
>
>> The failure is relatively new, and involves the diff tests. There is
>> work going on in this area and there have been failing tests in the
>> main test suite, so I suspect these are related. I have been holding
>> off looking at it until that work seems done, as I kind of expected
>> the test to start working again. Based on the assertion failure, it
>
>>
>
> I know what you mean. I was just getting excited to see a green build,
> after the Ruby bindings being the bad actor for such a long time. I
> should have realized you were tracking....
I was able to find the problem in the library and fixed it in r40148,
so the prodding was worthwhile!
I can fix the other JavaHL test by using --accept=theirs-conflict
instead of theirs-full. For the purposes of the test I was doing it
does not change anything. I worry that I am just covering up a real
error that needs to be fixed though. I am not clear as to why the
main tests are Green with this problem still in place. Every command
line user will see it when they use that accept option.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409799
Re: State of the bindings buildbot
Posted by Joe Swatosh <jo...@gmail.com>.
On Wed, Oct 21, 2009 at 6:26 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, Oct 21, 2009 at 1:36 AM, Joe Swatosh <jo...@gmail.com> wrote:
>
>> There is a Java error and failure also. I apologize for the long time
>> that the bindings buildbot has been failing due to Ruby, and masking
>> other potential problems. Now that the Ruby bindings are close to
>> passing again, I hope that the Java bindings will get fixed soon, too.
>
> The failure is relatively new, and involves the diff tests. There is
> work going on in this area and there have been failing tests in the
> main test suite, so I suspect these are related. I have been holding
> off looking at it until that work seems done, as I kind of expected
> the test to start working again. Based on the assertion failure, it
>
I know what you mean. I was just getting excited to see a green build,
after the Ruby bindings being the bad actor for such a long time. I
should have realized you were tracking....
Thanks,
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409797
Re: State of the bindings buildbot
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 21, 2009 at 1:36 AM, Joe Swatosh <jo...@gmail.com> wrote:
> There is a Java error and failure also. I apologize for the long time
> that the bindings buildbot has been failing due to Ruby, and masking
> other potential problems. Now that the Ruby bindings are close to
> passing again, I hope that the Java bindings will get fixed soon, too.
The JavaHL Error has been out there for a while and it also happens
with the command line. There is either no test for this, or someone
has abused (IMO) XFAIL. So when the core libraries fix this bug, then
JavaHL should start passing this test again. The problem is with the
--accept=theirs-full | base option when doing a merge.
The failure is relatively new, and involves the diff tests. There is
work going on in this area and there have been failing tests in the
main test suite, so I suspect these are related. I have been holding
off looking at it until that work seems done, as I kind of expected
the test to start working again. Based on the assertion failure, it
sounds like a bug in the main libraries and not JavaHL. I will take a
closer look when I get a chance.
Thanks for getting the Ruby bindings passing.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409778