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

On 2006-07-15 09:09:34 -0500, Ben Collins-Sussman wrote:
> On 7/13/06, Vincent Lefevre <vincent+svn@vinc17.org> wrote:
> >Subversion assumes that if the mtime value has not changed, then the
> >file of a working copy has not changed.
>
> Yes, this is a deliberate choice. Both CVS and Subversion examine
> current mtime, and compare it to a previously-recorded mtime to decide
> if further investigation (filesize comparison, brute-force comparison)
> is necessary. If CVS and Subversion didn't have this algorithm, then
> commands which scan the working copy (like 'svn status' and 'svn
> commit') would be orders of magnitude slower.

Not if you use both ctime and mtime (POSIX has been designed this way).
Not if you call the command on one file (e.g. "svn revert file").

And even if ctime didn't exist, one may prefer a (not necessarily)
slow and reliable behavior to a fast but possibly buggy behavior,
at least under some conditions (e.g. before whiping a working copy).

Now, since ctime exists, there's no reason not to use it (possibly
forwarding the request to APR if there's some limitation there).

Also, Subversion currently doesn't work as documented.

> >For instance, the commands "recode" and "mv" don't change the
> >mtime by default
>
> Don't do that. Use 'svn mv', not 'mv'.

There are several reasons why one can use mv. First, it can be by
mistake. Then, one may also really want to move some file, but only
the contents, not the svn history associated with this file (so
that "svn mv" would be the wrong command).

> >This is a rather nasty bug, as some changes may remain unnoticed,
> >and therefore, they may be lost.
>
> I don't understand, can you elaborate? Where's the risk of data loss?

Because one doesn't know that a file have modification. For instance,
if one whipes the working copy, one looses these modifications. Also,
one may want to modify the file, but with this bug, one would modify
the file that already has some possibly unwanted changes; this may be
fixable (using the history of the file), but not necessarily.

-- 
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