Philip Martin <firstname.lastname@example.org> 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
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).
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
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?)
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Oct 30 18:21:06 2003