Philip Martin <philip@codematters.co.uk> writes:
> I would not want 'svn status' to *require* a write lock, I want to be
> able to run it on working copies for which I don't have write access.
>
> 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).
> I think we would still need a way to prevent svn_client_status from
> taking write locks. Consider a long running GUI that periodically
> makes calls to svn_client_status to update it's view of the world. If
> the svn_client_status calls take write locks then that would mean that
> a command line commit would occasionally fail because it failed to get
> a write lock.
Good point, I hadn't thought of that. But still, if
1. Subversion operations are regularly fixing timestamps, and
2. otherwise-read-only operations only take out write locks when
the absolutely need to fix a timestamp(s), and
3. Subversion is careful to only take out the write lock once per
directory, and hold it only for as long as necessary to make all
the fixes in that directory
...then any given run of GUI status (or whatever) will not have many
write locks, and will not interfere with other things.
> > 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).
> > Philip, you pointed out (I think) the difference between a permanent,
> > operation-spanning write-lock and lots of little temporary ones which
> > would be released after being used. Why is the latter a performance
> > killer?
>
> The obvious implementation (the one I can see without thinking about
> it) would create and release a write lock for each timestamp changed,
> rather than once for the each directory. Think of the report we had
> some time ago of someone copying a working copy without preserving the
> timestamps, fixing that with temporary locks would involve two
> lock/release cycles for every file.
I was assuming the optimization of lock-once-per-directory; yes,
without that, the performance would be horrible. (Sorry, should have
been more explicit.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 20:34:13 2003