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

Re: State of the bindings buildbot

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 23 Oct 2009 15:49:38 -0400

On Wed, Oct 21, 2009 at 10:47 AM, Hyrum K. Wright <hyrum_at_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
>> <joe.swatosh_at_gmail.com> wrote:
>>> On Wed, Oct 21, 2009 at 6:26 AM, Mark Phippard <markphip_at_gmail.com>
>>> wrote:
>>>> On Wed, Oct 21, 2009 at 1:36 AM, Joe Swatosh
>>>> <joe.swatosh_at_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

*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 <dave.brown_at_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,


Received on 2009-10-23 21:49:46 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.