Stefan Sperling <s...@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