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

Re: [PATCH] Re: Issue #3354: copy operation during update fails

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 20 Jan 2009 11:23:33 +0000

I can explain the Linux-vs-Windows difference...

On Mon, 2009-01-19 at 14:24 -0500, Paul Burba wrote:
> 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:
> >>> 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.
[...]
> >>> 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!
> >>> =============================================================
[...]
> >>> 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

> > 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. [...]

> 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:
[...]

> 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.

I debugged this bit. It's the reliance on time stamps and file sizes to
detect whether the file has been modified. The old version of the test
changes the file content from

This is the file 'alpha'.<NL>

to

alpha, modified after move

which is the same length on Unix-style operating systems, but not on
Windows. The time stamp doesn't change when running the test suite
because of the "no sleep for time stamps" optimisation. Therefore the
"svn commit" would fail to see any change, on the Linux build-bots.

The new version of the test has <NL> after the new text, which makes the
file length change on all operating systems.

(If this problem bites us again or if we can think of a good solution,
we might want to do something about it, as it was an annoying sink of
debugging time.)

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1037686
Received on 2009-01-20 12:24:49 CET

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.