On Mon, Jan 19, 2009 at 11:17 AM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Sat, Jan 17, 2009 at 8:43 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Sat, Jan 17, 2009 at 03:40:57AM +0000, Stefan Sperling wrote:
>>> On Tue, Jan 13, 2009 at 08:45:36PM +0000, Stefan Sperling wrote:
>>> > I'm still hoping to get more eyes on trying to spot the real
>>> > bug though.
>>>
>>> Looks like the diff at the end of this mail fixes the problem
>>> properly.
>>
>>> I did not commit yet because I got test failures that happened during
>>> make check, but which I could not reproduce by running the failing tests
>>> individually.
>>
>> I ran make check again today and got 0 failures.
>> So I committed my diff in r35303.
>>
>> We still need to fix update_test 52, so I'll leave issue #3354 open
>> to track the status of the test.
>>
>> Stefan
>>
>>> Paul, I also tried running your test with this diff, without the XFail.
>>> But I could not get the test to do anything useful. All it does is
>>> complain about the root node of the working copy, and I don't understand
>>> what's going on there:
>>>
>>> $ ./update_tests.py 52 2>&1
>>> =============================================================
>>> Expected '__SVN_ROOT_NODE' and actual '__SVN_ROOT_NODE' in output tree are different!
>>> =============================================================
>>> EXPECTED NODE TO BE:
>>> =============================================================
>>> * Node name: __SVN_ROOT_NODE
>>> Path: __SVN_ROOT_NODE
>>> Contents: N/A (node is a directory)
>>> Properties: {}
>>> Attributes: {}
>>> Children: 1
>>> =============================================================
>>> ACTUAL NODE FOUND:
>>> =============================================================
>>> * Node name: __SVN_ROOT_NODE
>>> Path: __SVN_ROOT_NODE
>>> Contents: None
>>> Properties: {}
>>> Attributes: {}
>>> Children: None (node is probably a file)
>>> Unequal Types: one Node is a file, the other is a directory
>>> Output of commit is unexpected
>>> EXPECTED OUTPUT TREE:
>>> ROOT
>>> +-- svn-test-work
>>> +-- working_copies
>>> +-- update_tests-52
>>> +-- A
>>> +-- B
>>> +-- E
>>> +-- alpha.moved
>>> ACTUAL OUTPUT TREE:
>>> ROOT
>>> ACTUAL OUTPUT TREE:
>>> svntest.wc.State('svn-test-work/working_copies/update_tests-52/', {
>>> })
>>> EXCEPTION: SVNTreeUnequal
>>> Traceback (most recent call last):
>>> File "/home/stsp/svn/svn-trunk/subversion/tests/cmdline/svntest/main.py", line 1310, in run
>>> rc = self.pred.run(**kw)
>>> File "/home/stsp/svn/svn-trunk/subversion/tests/cmdline/svntest/testcase.py", line 121, in run
>>> return self.func(sandbox)
>>> File "./update_tests.py", line 4205, in update_moves_and_modifies_an_edited_file
>>> wc_dir)
>
> Stefan,
>
> So the commit of r3, 'Make a text mod to A/B/E/alpha.moved in the
> first WC' is failing. I can't replicate this on my Windows box (nor
> does the djh-xp-vse2005 box show it, but I see similar failures on all
> the non-Windows buildbots. So yeah, something is wrong with the test
> or some more general part of the test suite. Could you post the
> complete log for update_tests.py 52 along with the post-test verbose
> status of the 'other' WC that the test creates? That might shed some
> light on the problem.
Stefan,
r35322 had the wholly unexpected side-effect of making the Linux
buildbots get through the commit of r3 successfully. Now the two
Linux buildbots (that are not down because of unrelated build
problems) are failing because of remaining problems with issue #3354:
i686-debian-sarge1 shared gcc-3.3.5 -
http://www.mobsol.be/buildbot/i686-debian-sarge1%20shared%20gcc-3.3.5/builds/2047/step-Test%20fsfs%2Bra_svn/0
x64-ubuntu gcc -
http://www.mobsol.be/buildbot/x64-ubuntu%20gcc/builds/138/step-Test%20fsfs%2Bra_local/0
Please run the update_tests.py 52 again and see if you also get the
same failure as the buildbots.
Assuming you do get the same failure for a moment...
...the problem is that the change you made to
eval_conflict_func_result() in r35303 only applies during interactive
conflict resolution. If no interactive conlfict resolution is done,
then maybe_resolve_conflicts() never calls eval_conflict_func_result()
because the CONFLICT_FUNC argument to the former is NULL. (/me is
having a tough time with all the undocumented/minimally documented
functions in libsvn_wc/merge.c).
Paul
P.S. If you look, you'll see that all r32322 did that could affect r3
was to put a newline at the end of a text mod:
# r3: Make a text mod to A/B/E/alpha.moved in the first WC.
- new_content_for_alpha = 'alpha, modified after move'
+ new_content_for_alpha = 'alpha, modified after move\n'
svntest.main.file_write(alpha_moved_path, new_content_for_alpha)
How the lack of a newline causes the test suite to fail the commit of
r3 is an open question and one that I have little chance of answering
because I can't replicate it on my Windows box.
Received on 2009-01-19 20:27:59 CET