Philip Martin <philip@codematters.co.uk> 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.
Heh. Here's what I'm proposing:
'svn status' uses read locks by default. When it encounters a
timestamp(s) that need fixing, it attempts to convert the appropriate
read lock to a write lock. If it succeeds, it fixes the timestamp.
If it fails, it does not error, it just doesn't fix the timestamp.
(Of course, the reality will be slightly more sophisticated: it will
learn everything it can about a directory first, so it only has to get
a write lock once. But that's just an optimization, albeit a
necessary one for performance reasons.)
> 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.
Yes -- facts that were expensive to discover can be cached.
> 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!
I'm not as uncomfortable with it as you are. I guess I started out
from the point of view that managing the working copy is Subversion's
business -- any Subversion operation can do whatever it feels is
appropriate to make things work nicely. We developers are used to
thinking of 'svn status' as read-only, and now we're considering it as
read-write, only because we're aware of the underlying implemention of
.svn dirs and lockfiles. None of that stuff matters to the user.
They'll just be happy if things run faster.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 22:16:25 2003