Philip Martin <philip@codematters.co.uk> writes:
> That's better from an implementaion/performance point of view, but I'm
> not convinced that we really want it in the default status output. We
> come back to my suggestion 1) an additional option to status, one that
> causes it to take out a write lock, and to report and repair broken
> timestamps.
Before anything else: yay Philip for attacking issue #791! This will
really help client performance.
On to current questions:
I have to agree with Julian, that exposing this implementation detail
to the user is soooo not the road to go down.
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).
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.
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.
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? 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.
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.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 18:21:06 2003