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

Re: svn commit: r964471 - /subversion/trunk/subversion/libsvn_client/update.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 15 Jul 2010 21:18:13 +0100

"Bert Huijben" <bert_at_qqmail.nl> writes:

>> -----Original Message-----
>> From: philip_at_apache.org [mailto:philip_at_apache.org]
>> Sent: donderdag 15 juli 2010 17:42
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r964471 -
>> /subversion/trunk/subversion/libsvn_client/update.c
>>
>> Author: philip
>> Date: Thu Jul 15 15:41:32 2010
>> New Revision: 964471
>>
>> URL: http://svn.apache.org/viewvc?rev=964471&view=rev
>> Log:
>> * subversion/libsvn_client/update.c (internal_update): Don't unlock
>> here.
>
> Why?
>
> It's the responsibility of the caller to obtain and release the
> locks, just like in the access batons or we break al the access
> baton functions. (I know that the update_editor releases locks in
> some cases where it didn't in 1.6.. This might be the cause of the
> dav failures)

The caller, svn_client__update_internal, does lock and unlock. Having
internal_update unlock and then having the caller unlock as well is
wrong.

-- 
Philip
Received on 2010-07-15 22:18:55 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.