[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: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 15 Jul 2010 22:22:09 +0200

> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: donderdag 15 juli 2010 22:18
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r964471 -
> /subversion/trunk/subversion/libsvn_client/update.c
>
> "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.

Ok, thanks for explaining. (Maybe we should move some of this in the log
message?)

        Bert
Received on 2010-07-15 22:23:28 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.