[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Fixing time stamps

From: <kfogel_at_collab.net>
Date: 2003-10-30 17:41:20 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.