[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue #4162: make svn status fix timestamp mismatches in meta-data

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 23 Jun 2014 11:40:55 +0200

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

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

Received on 2014-06-23 11:41:48 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.