Re: script to detect timestamp-mismatches (inefficiency) in (1.7) working copies?

Stefan Sperling <stsp_at_elego.de> writes:

> Of course, this would require 'svn status' to obtain a write lock on wc.db.
> The status operation must not hold a write lock during regular operation
> because doing so prevents concurrent read access by other clients.
> To keep the time window where the write lock is held as small as possible,
> we could collect a list of affected files during the status run while
> a read-lock is held and update timestamps after the status run for those
> affected files which still have the same timestamp they had during the run.

That might cause problems for multi-threaded GUIs. If one thread is
running status to update the display it could cause another thread
attempting update to fail because status has a lock. So a GUI might
want to be able to force status to remain read-only. Which means the
GUI has to repair timestamps some other way: by running cleanup at
intervals say and being aware that the wc is locked.

-- 
Philip