On 2006-06-30 20:33:08 -0500, Peter Samuelson wrote: > mv within a subversion working copy isn't supported anyway; what you do > instead is 'svn rename' or 'svn copy'.
mv *must be* supported. It's a Unix command and the user is allowed to use it. I'm not saying that I want that same behavior as "svn rename". I just expect that if I do "mv some_file other_file", then subversion should report some_file as missing and other_file as modified (if the file contents were different). > > Other Unix programs won't lead to lost data because of a different > > mtime (unless the user explicitly tells the command to consider > > mtime, e.g. with "cp -u"). > > They'll do things just as bad. 'find -mtime -5' will not find files > modified in the past 5 days. 'make' will not rebuild programs whose C > files you have changed. 'tar --newer-mtime' will not back up files > which have changed more recently than your previous incremental backup. > Do you think any of those effects are desirable? Yes, this is a documented feature (which can be disabled), whereas in subversion, it is not a feature; for instance, "svn help st" says: With no args, print only locally modified items (no network access). i.e. "modified items", not "modified mtime". > > Subversion doesn't need to do the same thing under Windows and OS/2 > > (Subversion already has features that depend on the OS, e.g. symlinks > > support). > > The problem here is that, while subversion uses a portability library > called apr, apr itself has different behavior with respect to ctime on > different platforms. On Unix and Netware, it presents inode change > time. On Windows and OS/2, it presents file creation time (which > doesn't exist at all on Unix). Goodness only knows what it does on > OS/400. I still can't send this patch upstream, it's too ugly to make > it depend on "whether the ctime field is available and means what we > think it means". Then apr is very badly designed. The creation time is something completely different than the inode change time. So, apr shoudn't present them under the same name. Anyway, why wouldn't this work on Windows and OS/2? If the creation time is modified, this means that the file is different (well, should be, but subversion then looks at the contents anyway); and if the creation time is not modified, then the behavior would be the same as not looking at it (i.e., the same as before). > Please also explain why you think the mtime field is useful at all. I > don't understand your logic that it's useful for some things but not > for others. If you'd like to argue that mtime should be ignored in all > unix applications and only ctime used, that would be more consistent. I'm not saying that. I'm saying that mtime is a user field, that can be set by some programs for a good reason. Don't you agree that "mv" should keep the old mtime? Some commands (e.g. find -mtime, make, cp -u) *explicitly* use the mtime, as documented. This is not the case of subversion, whose goal (as documented) is to consider the file contents. Any optimization should be safe. So, in addition to mtime, subversion should look at other fields. I'm not sure whether ctime is sufficient or if subversion should look at the inode number too. -- Vincent Lefèvre <[EMAIL PROTECTED]> - 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
