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

Re: [PATCH] Fix for issue 1797 - take three

From: makl <makl_at_tigris.org>
Date: 2004-04-08 18:54:57 CEST

Philip Martin wrote:

> makl <makl@tigris.org> writes:
>>Index: subversion/libsvn_wc/lock.c
>>--- subversion/libsvn_wc/lock.c (revision 9290)
>>+++ subversion/libsvn_wc/lock.c (working copy)
>>@@ -329,22 +329,29 @@
>> static svn_error_t *
>> do_open (svn_wc_adm_access_t **adm_access,
>> svn_wc_adm_access_t *associated,
>>+ const svn_wc_adm_access_t *root_associated,
> I don't see why you added this additional access baton parameter, it
> looks like you could just use associated.

Look at the recursion. In the next subdirectory, associated has an empty

>>+ if (lock == &missing)
>>+ lock = NULL;
> I think we need to verify the type of the lock, if write_lock is set
> it's probably not acceptable to use a read-only lock.

missing is a static entry declared in line 80. It has no meaningful
information, so there is nothing to check.

> Hmm, now I see you are upgrading read-only locks into write locks, but
> you didn't document this behaviour anywhere. As far as I can tell it
> even upgrades existing read-only locks! That won't work, not unless
> the entries cache is thrown away and repopulated. I don't like it,
> I'd prefer locks not to change type. That's the reason
> adm_access_alloc takes a lock type; once allocated it never changes.

Can we accept write locks if read locks are requested?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 8 18:53:04 2004

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.