On Mon, Jun 23, 2014 at 11:08 AM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Julian Foad [mailto:julianf...@btopenworld.com] >> Sent: maandag 23 juni 2014 10:03 >> To: Markus Schaber >> Cc: Subversion Dev (dev@subversion.apache.org) >> Subject: Issue #4162: make svn status fix timestamp mismatches in meta- >> data >> >> Markus Schaber wrote (in thread "controversial issues in the tracker"): >> >> > * 4162 make svn status fix timestamp mismatches in meta-data >> > http://subversion.tigris.org/issues/show_bug.cgi?id=4162 >> > >> > The controversial issue here is whether it is a good idea to have "svn >> > status" modify the meta data - until now, it intentionally only has a >> > read-only lock on the working copy, and changing that may have >> compatibility >> > side effects. >> > >> > Currently, correcting the metadata for files with updated timestamps (but >> > unmodified content) is only available as a side-effect of other commands >> > (update, cleanup, etc.) which all have other side-effects. >> > >> > Thus, alternative solutions may be to pass an option to status which >> explicitly >> > allows modification of the meta data, or create a command (or option to >> svn >> > cleanup) which only fixes the timestamps without other side effects. >> > >> > My personal suggestion is to add a flag to svn status. >> >> I'm with Stefan Sperling: the user doesn't want to know or care about this. >> It's just caching. We don't need another flag or command or explicit action >> to >> control it. Subversion should simply update the metadata. > > > Changing the recorded timestamps would require obtaining a write lock while > performing a status walk... which is a breaking change for any client that > wants to do things concurrently. > > -1 on 'just doing it' > > There is a good reason the current code only updates timestamps when it has a > write lock. Otherwise it would break concurrent operations. > > > Note that 1.9 already supports an api to fix timestamps at the api level: you > can now run cleanup without breaking the write locks. > >
Another option is to let 'svn status' report on the amount of mismatching timestamps, possibly controlled by some verbosity flag. That doesn't require a write lock, and 'svn status' can gather this information for free (at the cost of some memory for keeping the stats) during its status walk: it already enters a specific code path when a file has mismatching metadata yet its content is unmodified (see the patch to subversion/libsvn_wc/questions.c mentioned in [1]). At least this has the possibility to give the user some feedback on the amount of "metadata-mismatch" in his working copy. Right now, the user could be working for a long time with a working copy that has almost 100% mismatching metadata. It will be dog-slow, and the user will not know why. Note that timestamp-mismatch does not only happen because of SVNKit (see [1]), but also for instance when a user copies his entire working copy accross filesystems. This happens quite frequently: when users get a new pc, they often want to just copy their old working copy to the new disk. At least on Windows, this yields 100% timestamp mismatches because all last-mod-timestamps of the files are changed (also on unix, unless they use -p or a similar flag to preserve last-mod-timestamps). Something like "Warning: working copy has 95% incorrect metadata, resulting in slow performance. Please run 'svn bla' to make it fast again." might help. [1] http://issues.tmatesoft.com/issue/SVNKIT-315 -- Johan
