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

Re: switch_tests.py 21 failing with serf

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 13 Jul 2010 13:29:17 -0400

On 07/05/2010 12:31 PM, Philip Martin wrote:
> switch_tests.py 21 is failing when I use serf although it passes when
> I use neon. The test involves a switch that fails because a directory
> to be added is obstructed by an unversioned directory. This causes
> the switch to fail and the test then fails because serf and neon do
> things in different orders. For two sibling directories neon calls:
> add_directory
> close_directory
> add_directory
> close_directory
> but serf calls:
> add_directory
> add_directory
> close_directory
> close_directory
> The add_directory calls add an incomplete directory that is made
> complete by the close_directory call. So if the second add_directory
> fails the status of the first directory added depends on which http
> library is in use.
> I am aware that there are ordering issues with serf, is this one of
> known ones?

I'm not exactly sure, but yes, I believe this is just such a Serf ordering
situation. My understanding is that update/switch/etc. fire off handlers
for property and file content fetches, and I think those handlers (which can
run in parallel, kinda) open or add directories (via the editor) on an
as-needed basis, making the actual call ordering somewhat difficult to predict.

> Also, when the add_directory call in libsvn_wc returns an error back
> to serf the switch doesn't immediately abort, it calls add_directory
> on the failing path two more times. Is this the way it's supposed to
> behave?

That sounds wrong, but not altogether unbelievable if in fact three
different fetch handlers are each trying the add_directory() in turn and not
sharing the failures with each other.

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-07-13 19:29:58 CEST

This is an archived mail posted to the Subversion Dev mailing list.