On Fri, Apr 20, 2012 at 11:59:32AM +0100, Philip Martin wrote: > 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.
We can grant control over this at the API level via, say, a new boolean parameter 'fix_timestamps' in svn_client_status(). We'd probably need this anyway to provide the current behaviour in backwards-compat APIs. If the GUI application has a choice in the matter, by allowing or disallowing a status run to update timestamps, it can synchronise its own threads accordingly. I'm fine with bothering client developers with this little detail. I object to bothering end users with it unless there is no other way. You're not arguing about inter-client effects, right? I.e. a GUI client trying to update its icons while a command line client 'svn status' run is updating timestamps? This situation isn't much different to a command line client performing a concurrent update or commit, which GUIs need to deal with anyway.
