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

Re: Nasty double-replace copy-on-update bug

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2007-10-19 19:16:29 CEST

"David Glasser" <glasser@davidglasser.net> writes:

> On 10/19/07, Philip Martin <philip@codematters.co.uk> wrote:
>> "David Glasser" <glasser@davidglasser.net> writes:
>> > On 10/19/07, Philip Martin <philip@codematters.co.uk> wrote:
>> >>
>> >> Without a write lock some other Subversion process could change or
>> >> delete the file in the interval between the decision to use a file and
>> >> the moment it gets used.
>> >
>> > Huh. When is it ever safe to not take the write lock, then?
>> When doing a read-only operation such as status.
> OK, so what matters is the overall user-level (svn_wc-level?)
> operation, not the particular purpose that the adm_access is being
> grabbed for? (Because here, the baton is being grabbed just for
> reading; a different, locked baton is used to write...)

Yes. The locks are not read-write locks, I suppose they could be
described as "write-exclusive" locks as a lock excludes other writers.
In the past write operations that I worked on grabbed all needed locks
before starting, attempting to extend an access baton set was tricky.
I don't really know how the _try interface works and I don't know
whether it properly closes batons in the presence of "holes" (see the
comments above lock.c:do_close). I've mostly given up hacking on the
wc code because it is simply too horrible.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 19:16:43 2007

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.