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

Stefan Sperling <stsp_at_elego.de> writes:

> 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.

It's probably OK. What about wc format auto-upgrades? In the past we
had read-only operations that retained the old format and write
operations that auto-upgraded. Does status auto-upgrade? Have we
stopped auto-upgrading altogether?

Note that when status acquires the lock it has to repeat the timestamp
check, it cannot be assumed that the timestamp is still broken, or that
the file still exists, or that it is still a file, etc.

-- 
Philip