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

Re: svn commit: r1099094 - /subversion/trunk/subversion/libsvn_ra_serf/commit.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Wed, 28 Aug 2013 18:14:05 +0100

Ben Reser <ben_at_reser.org> writes:

> On 8/28/13 7:35 AM, Ivan Zhakov wrote:
>> Bert refers to r712674 [1] -- 4 years old change in APR, so it should
>> not be issue now.
>>
>> @Bert: Do you remember why temporary file could be not removed on file close?
>>
>> [1] http://svn.apache.org/viewvc?view=revision&revision=r712674
>
> Unless we've raised our requirement of APR to not allow versions that
> have this issue we should leave any workarounds we have for it in. We
> end up with a lot of users running on old Linux distros that use
> whatever APR is provided by the distros. Heck our own CentOS buildbot
> is one of these cases, it's using APR/APR-Util 1.2.7 which was released
> April 14th, 2006.
>
> If you want to avoid the workarounds for newer APR versions that you
> detect at runtime I'd support that.
>
> I'd support us raising our APR version requirement in Subversion 1.9.x
> to APR 1.3.x, not sure if that helps in this case.

The Subversion change (r1099094) was to revert svn_io_file_del_on_close
back to svn_io_file_del_on_pool_cleanup. The APR change (r712674) was a
fix for APR_DELONCLOSE so I suppose that svn_io_file_del_on_close might
not work properly with old APR.

I don't recall the exact details of what, if anything, failed. I don't
know whether Bert was worried about some specific ra_serf problem with
using svn_io_file_del_on_close or whether it was just a general
observation that there was an APR bug. There are other places in the
current Subversion source code that use svn_io_file_del_on_close so we
don't appear to have a blanket ban on using it.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2013-08-28 19:14:44 CEST

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.