subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <s...@elego.de>
Subject Re: Timestamp issue with "svn status" in 1.9.3
Date Fri, 04 Mar 2016 15:17:13 GMT
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.

Mime
View raw message