> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: maandag 23 juni 2014 11:41
> To: Bert Huijben
> Cc: Julian Foad; Markus Schaber; Subversion Dev
> Subject: Re: Issue #4162: make svn status fix timestamp mismatches in meta-
> data
>
> On Mon, Jun 23, 2014 at 11:08 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> >
> >
> >> -----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.
> >
> >
>
>
> 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
Why should we try to fix an SvnKit problem (of not recording the actual timestamp, but only an arbitrary rounded value) in Subversion itself?
I don't think we should expose a value like that in our higher layers... Ordinary users wouldn't know what to do with it anyway.
And doing something like running a recursive 'svn commit' (or any other status performing code with a write lock) on your working copy will already fix all your timestamps for you.
If you have 95% invalid recorded timestamps you have bigger problems... And those problems should (if they are related to some Subversion client) be fixed at the origin (SmartSVN?), not at all other locations.
(FYI: Recent versions of SmartSVN now use JavaHL, see http://www.wandisco.com/smartsvn/changelog.txt)
Bert
Received on 2014-06-23 12:04:22 CEST