> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: maandag 23 juni 2014 10:03
> To: Markus Schaber
> Cc: Subversion Dev (dev_at_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.
Bert
Received on 2014-06-23 11:09:20 CEST