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

Re: svn trunk r21152: FAIL (i686-debian-sarge1 shared gcc-3.3.5)

From: Paul Burba <paulb_at_softlanding.com>
Date: 2006-08-22 17:58:14 CEST

rooneg@gmail.com wrote on 08/21/2006 04:27:14 PM:

> On 8/21/06, buildbot@mobsol.be <buildbot@mobsol.be> wrote:
> > Full details are available at:
> > http://www.mobsol.be/buildbot/i686-debian-sarge1%2520shared%
> 2520gcc-3.3.5/builds/349
> >
> > Author list: pburba
> >
> > Build Slave: eh-debsarge1
> >
> >
> > Subversion Buildbot
> > http://www.mobsol.be/buildbot/
>
> It looks like this failure is in the two tests that Paul just added.
> I'm seeing the same failures here (I think, can't get much info from
> the buildbot log), and it's an output ordering issue, nothing earth
> shatteringly interesting. Paul's looking at a fix now.

As discussed some time back in IRC the problem is in libsvn_client/add.c
add_dir_recursive() which calls svn_io_dir_open(), i.e. apr_dir_open().
Within a for loop we call svn_io_dir_read(), i.e. apr_dir_read(), to add
each child. The problem is apr_dir_read() doesn't guarantee any ordering
for the entries read -
http://apr.apache.org/docs/apr/group__apr__dir.html#ga2

Ultimately this means that svn add may report added paths in any order. My
new tests in r21152 used svntest.actions.run_and_verify_svn() to run svn
add with a hardcoded list of paths as expected output, and of course the
order of the paths is what passes on my XP box :-) I modified the tests
to perform the adds without caring about the output and instead confirm
the adds with run_and_verify_status().

Note: The other svntest.actions functions that run specific commands, e.g.
run_and_verify_commit(), run_and_verify_checkout(), etc., compare tree
structures which are not sensitive to order. The more generic
run_and_verify_svn() just dumbly compares a subcommand's output list with
the list we pass it.

Anyway, Garrett, if you (or someone else running debian) have a moment to
check if this patch solves the problem that would be great. Worst case,
if no one has time for this I can commit it and let the buildbot test it.
Normally I wouldn't do this, but I'm quite confident this patch solves the
problem (famous last words I know).

Paul B.

[[[
Fix false copy test failures due to dependence on added path notification
order.

Follow-up to r21152. Python tests should not rely on a specific
notification
order of paths when running svn add as the order of these paths is
ultimately
tied to apr_dir_read() which does not guarantee any order.

* subversion/tests/cmdline/copy_tests.py
  (copy_move_added_paths, copy_added_paths_to_URL): Set expected_stdout
  to None when calling run_and_verify_svn() to add paths. Instead,
confirm
  paths were added correctly with run_and_verify_status(). Also make some
  minor comment improvements and create consistent unversioned paths in
both
  tests.
]]]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Tue Aug 22 18:02:56 2006

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.