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

Re: svn trunk r15420: FAIL (win32 ra_local fsfs)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-07-25 17:25:13 CEST

D.J. Heap wrote:

> The Win32 tests are failing in repos authz tests again due to the same
> problem I fixed a few weeks ago -- the temp config file cannot be
> opened by the config parsing routines because they don't use APR and
> on Win32 stdio wants an exclusive lock on the file.
>
> Previously, I fixed it by changing the test to manually close and
> delete the file so it would be available for the config routines.
> However, it seems like it may be better to just fix the config parsing
> to deal with different types of line endings and make it use APR so
> this type of problem doesn't come up any more. I haven't looked at it
> really closely to determine how hard that would be.
>
> Any thoughts or opinions on whether to just fix the test, or to change
> the config parsing code to use APR and deal with different line endings?
>
> Fixing the test is much simpler, but seems prone to re-introduction
> again (whether in tests or in production). I'm not an expert on the
> config parsing code, but if servers are going to use it they could
> have a concurrency problem unless some sort of another ugly retry-loop
> is used, couldn't they?

Ah, I'd always wanted to kill that bit of stdio in our code and
introdice an eol-anonicalizing svn_stream_t. One of those would also be
useful in all the places where we generate configuration files, and
currently use APR_EOL_STR in the code because we can't rely on eol
conversion (and we miss the APR_EOL_STR in some places, notably the
.subversion/config file. :)

I'd much rather do this and _not_ have the config parsing code fiddle
with different line endings. I think we already have most of the logic
in the (de)translation code anyway, it just needs to be extracted into a
new stream type.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 25 17:26:23 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.