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

Re: 1.1.4 Win32 test results

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-04-03 21:08:21 CEST

Erik Huelsmann wrote:

>>>"Erik Huelsmann" <e.huelsmann@gmx.net> writes:
>>>
>>>
>>>
>>>>- repos_tests.exe FAILs: it's not the tests themselves, but the
>>>> cleanup afterwards which removes the repository directories.
>>>> Nearly the only thing which happens in that cleanup is a call to
>>>> svn_io_remove_dir(). So, I inserted a sleep() call before that:
>>>> Now the tests (and their cleanup) succeed. I just checked: 1.1.3
>>>> had the same failure.
>>>>
>>>>This is not a problem of the tests themselves, I would like to know if
>>>>we should add a retry loop the same as with deleting files.
>>>>
>>>>
>>>svn_io_remove_dir already has a retry loop, does it need to wait
>>>longer?
>>>
>>>
>>I guess it does. A 'sleep(1);' call fixes it consistently.
>>
>>Even though the problem isn't currently visible on trunk, it suddenly
>>disappeared without being addressed. I guess other code changes have
>>resulted in slightly different timings on the test box. That doesn't mean
>>that it won't occur to others, though.
>>
>>
>
>On second thought, it may need to check extra errors.
>
>The error returned was 'Dir not empty', but the retry loop only checks for
>Access denied and Sharing violation. Searching through the APR headers
>there's also ERROR_DIR_NOT_EMPTY. I'll be running checks with this error
>code added to the retry loop: Branko said you can't depend on files
>disappearing immediately after deletion on Win32....
>
>
Yep, that's a fact. Yuck, bletch, and all that. Since svn_io_remove_dir
is recursive, I suppose retrying on DIR_NOT_EMPTY is valid.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 3 21:11:32 2005

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.