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

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

From: Peter Samuelson <peter_at_p12n.org>
Date: 2006-07-15 16:27:40 CEST

[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

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.


  • application/pgp-signature attachment: stored
Received on Sat Jul 15 16:28:19 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.