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

-- 
Johan