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

Re: Timestamp issue with "svn status" in 1.9.3

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 4 Mar 2016 16:17:13 +0100

On Fri, Mar 04, 2016 at 12:54:42PM +0100, Peter Klotz wrote:
> Hello Subversion Developers
>
> We encountered a strange issue with Subversion 1.9.3 (running under RHEL 7). The attached script demonstrates the behavior.
>
> When changing the timestamp of a file to an earlier point in time and leaving the file size unchanged yet altering the content, Subversion is not always able to detect this change.
> The attached test case is the simplest we could come up with that reliably reproduces the problem.
>
> Regards, Peter.

Subversion uses timestamp and size as a short-cut for detecting unmodified
files. This saves Subversion from having to run a full content comparison
for every file in the working copy when 'svn status' is run under what
we'd consider "normal" conditions. You are artificially creating conditions
which fool Subversion into believing the file was not modified. Because the
timestamps and size checks which precede a full content comparison indicate
the file was not modified, the full content comparison is skipped and the
modification remains undetected.

So, that's why you're seeing this behaviour. What's unclear is why you are
investigating this behaviour in the first place. What is your use case for
changing the file's content but leaving it's timestamp unchanged?

Does the use-commit-times option help your use case, perhaps?
See http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts
and search for 'use-commit-times' on this page.
Received on 2016-03-04 16:17:26 CET

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

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