Stefan Sperling <s...@elego.de> writes:
>> --- subversion/libsvn_wc/lock.c (revision 903527)
>> +++ subversion/libsvn_wc/lock.c (working copy)
>> @@ -1857,9 +1857,10 @@
>> apr_pool_t *result_pool,
>> apr_pool_t *scratch_pool)
>> {
>> + svn_error_t *err1, *err2;
>> SVN_ERR(svn_wc__acquire_write_lock(NULL, wc_ctx, local_abspath,
>> scratch_pool, scratch_pool));
>> - return svn_error_compose_create(
>> - func(baton, result_pool, scratch_pool),
>> - svn_wc__release_write_lock(wc_ctx, local_abspath, scratch_pool));
>> + err1 = func(baton, result_pool, scratch_pool);
>> + err2 = svn_wc__release_write_lock(wc_ctx, local_abspath, scratch_pool);
>> + return svn_error_compose_create(err1, err2);
>> }
>>
>> However, if I make that change I get several test failures:
>
> Are these related to the svn_wc_notify_t-related issues you found?
No, those were separate and are now fixed.
> Can we apply your patch to fix the ordering problem?
I think we should apply it, but the patch tests fail.
It raises the question: why are the patch tests taking a lock? They
seem to pass without the lock. Does this mean the lock is
unnecessary? Or does it mean that there is some code that requires a
lock but is not checking to make sure that a lock is held?
--
Philip
