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

svn doesn't report modified file when timestamp has not changed

From: Vincent Lefevre <vincent+svn_at_vinc17.org>
Date: 2006-07-14 03:12:04 CEST

Subversion assumes that if the mtime value has not changed, then the
file of a working copy has not changed. This assumption is wrong under
Unix. For instance, the commands "recode" and "mv" don't change the
mtime by default (with "mv", the timestamp of the original file is
kept, which leads to the problem when one overwrite a file with a
different file that has the same timestamp); concerning "mv", this
behavior is even required by POSIX:


According to a discussion in November 2002 ("svn status: does not
notice changed file if timestamp of "new" file is older") concerning
the behavior under Windows, it seems that Subversion did the right
thing (under Unix) in the past:


and the change was done due to the Windows behavior (probably
because APR regards ctime as the creation time under Windows,
which is inconsistent with the Unix meaning of ctime).

Indeed, under Unix, if max(mtime,ctime) is the same, then it is
almost guaranteed that the file has not changed.

This is a rather nasty bug, as some changes may remain unnoticed,
and therefore, they may be lost.

I also reported this bug in the Debian BTS:


Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 14 03:12:35 2006

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.