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
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 <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,
right?
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2410755
Received on 2009-10-23 21:49:46 CEST