kfogel@collab.net writes:
>> Are you suggesting that status should attempt to take out a write
>> lock, and if that fails take out a read lock? I hadn't thought of
>> that. I guess that would be possible, but there would still be a
>> performance hit.
>
> Exactly, yes. The performance hit would only happen in the case where
> timestamp fixing was needed (see below).
Exactly, yes or exactly, no? I'm confused. Do you mean a status
implementation that tries to get write locks before crawling the
working copy and if it fails falls back on read locks, or one that
starts with read locks and converts to write locks as it progresses?
I was thinking of the former, but you appear to be thinking of the
latter.
>> > But anyway, why is converting a read-lock to a write-lock more
>> > expensive than having the write lock in the first place? In both
>> > cases, a lock file must be dropped into .svn/. And a bit set in a
>> > structure in memory, I suppose, but that's clearly not the expensive
>> > part.
>>
>> This is the important point: read locks do not create a lock file.
>> That makes write locks more expensive, particularly if the working
>> copy is on a network filesystem.
>
> Sure. I thought you were saying that taking out write locks on demand
> would be more expensive than taking them out in advance, and was only
> questioning that assertion (which you may not have been making).
On demand can be more expensive if it is trying and failing. It is
generally cheaper to try and fail once at the start than to try and
fail each time a broken lock is encountered. I suppose we could store
the fact that we failed and not try again.
> I was assuming the optimization of lock-once-per-directory; yes,
> without that, the performance would be horrible. (Sorry, should have
> been more explicit.)
It happens automatically if read locks are converted into write locks
on demend, but if we use temporary write locks it's needs more
thought.
I am still uneasy about the whole idea of having read locks convert
into write locks. It takes away my ability to be sure that an
operation is read only. Suppose some operation doesn't work the way I
expect, how do I investigate it? Simply running 'svn status' might
change the working copy. I might have to start using two usernames,
one without write access!
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 21:05:20 2003