kfogel@collab.net writes:
> But, I don't see why it's so bad for 'svn status' to take out a write
> lock (obviously, it shouldn't error if it can't -- it just wouldn't do
> the repairs, in that case).
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.
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.
> Also:
>
> Why is it bad, performance-wise, for a read-only operation like status
> to convert read-locks to write-locks on the fly? It would only have
> to do it in the directories where it detected problems, and of course,
> next time around that directory likely wouldn't be a problem -- so any
> given run of status is not likely to be slowed down too much.
Permanent on-the-fly conversion is probably not that bad in
performance terms, just a bit tricky to handle as far as program logic
goes. The following pseudo-code works perfectly at present since read
locks are a pure memory structure
frobnicate()
{
read_lock = svn_wc_adm_open(...)
if (foo (read_lock))
{
write_lock = svn_wc_adm_open(...)
bar (write_lock)
svn_wc_adm_close (write_lock)
}
}
If read locks sometimes become write locks then the function will
sometimes fail (I'm holding read_lock and write_lock simultaneously).
It might never happen during testing, bug reports are likely to say
something like "it occasionally fails, but if I run it again it just
works".
> 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.
> 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.
> In both cases, each lockfile used needs to be both created
> and removed. But if you just lock individual directories when you
> need a lock, then fewer lockfiles will be created and removed in
> total, so I'd actually expect that strategy to be *better*,
> performance-wise. (Incidentally, it shouldn't matter whether the each
> lock is removed immediately after being used, or all the locks removed
> at once at the end, should it?)
>
> Finally:
>
> In theory, it's nice that status doesn't block other operations. But
> in practice, how often does it really matter? I doubt most Subversion
> users would notice if status started taking out write-locks.
Probably not if they are only using one application. If multiple
applications run in parallel they may get problems.
> Again, if for whatever reason a write-lock can't be obtained, it
> wouldn't be an error. The operation simply wouldn't repair the
> timestamp; no big deal.
We would also need more code in status to distinguish the locks taken
by status from the locks that existed before status was run. I don't
want status to tell me that every directory is locked.
--
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 20:08:52 2003