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

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

The counter-argument is that the documentation says you can use any
normal file manipulation commands to play with your wc. 'mv' is
certainly one. If mv is dangerous, which it is if you're using it
between two checked-out files (which often have the same mtime because
they were checked out together), it might be worth mentioning this.

> I don't understand, can you elaborate? Where's the risk of data loss?

This came up because someone tried to use GNU recode, which can edit a
file's character encoding "in situ". When doing so, it has the
"interesting" default behavior of resetting the mtime to hide the fact
that it modified the file. The documentation justifies this "feature"
by saying that your data was not, after all, _really_ changed.

Now, call me dense, but I cannot fathom how this "feature" can possibly
be considered desirable as default behavior. Yet the author has
weighed in and reaffirmed that he sees nothing wrong. See
http://bugs.debian.org/376124.

Anyway, if you run 'recode' on your wc file, and someone else checks in
a newer version, the next 'svn update' will overwrite your
modifications. This is the data loss Vincent is referring to.

Peter