Johan Corveleyn wrote:
>> A few of these are Windows-specific. I can't very well investigate those
>> myself. Who could volunteer to look at those? They are:
>>
>> externals_tests.py ... ... ...:
>> update_modify_file_external(),
>> remap_file_external_with_prop_del(),
>> file_external_recorded_info():
>> existing issue (Windows only)
>>
>> These tests are commented with "# Existing issue: `src_stream` not
>> closed in externals.c:apply_textdelta()"
>>
>> Does that mean it's a problem already on trunk? Or a hidden problem? If
>> someone could please take a look, that would be great. If not, could
>> anyone volunteer to test a possible fix if one of us unixers made a guess?
>
> I have no idea what those tests are about, but I can probably help
> test things on Windows.
> I'll try to get the branch built on my Windows machine tonight, and
> then I can help try out various things.
Great! Thanks.
I found also this one is a Windows-only test:
update_tests.py 57 skip_access_denied(): access denied paths should
be skipped
(In principle I don't see why we shouldn't test a similar access-denied
condition on unix-like systems, though the error code would be
different. Maybe the answer is the semantics would be so different it
would fail at a different place in the code path and so be a different
test case. I don't plan to pursue this.)
I think the current state is this test will report XFAIL/WIMP with
pristines-on-demand enabled (currently meaning WC format 32) and XPASS
otherwise.
This test was introduced in r1143071 with the log message "Make svn
update handle some access denied scenarios with a proper skip. This
makes it less likely that the database will be closed after updating with
working queue items left."
I would guess that gracefully handling the case where the working file
on disk has this particular kind of OS lock isn't of primary concern.
- Julian
