On 2006-07-01 20:23:09 -0500, Peter Samuelson wrote: > [Vincent Lefevre] > > And again, this problem is not specific to "mv". MUAs also set the > > mtime to the old value when modifying an mbox file (for some > > technical reason). > > I never quite understood the timestamp manipulations of mbox files > either. Something to do with being able to tell whether the user has > any new, unread mail - if atime > mtime, you have new mail, if mtime > > atime, you don't.
The opposite. > Or something like that. It's a pretty atypical use of these fields, > though. Yes, but one has to cope with that. :( > > > Because subversion doesn't store both the ctime and the mtime, so > > > you have to pick one. Obviously you can't pick ctime if it means > > > file creation time. > > > > Subversion could be modified to store both (when ctime is supported). > > That's, again, a change to the working copy format. Read your nearest > .svn/entries file some time and you'll see what I mean. Actually don't > bother, that would give you the wrong idea, that you could just extend > the XML schema a bit. In reality the XML is going away in 1.4.0. (: I wonder if the new format allows to add fields that could be ignored with old clients (in which case this would not be a problem IMHO). I read a thread about the new format, but I don't remember (and I always thought that XML was a better idea for its flexibility in particular). Anyway, instead of the ctime value, Subversion could store max(mtime,ctime). Wouldn't this work (even with APR's ctime for the other OS such as Windows)? > > > > You're dodging the question, because you think 'find -mtime' is an > > > exception because it refers explicitly to the mtime field. OK, so > > > what about 'find -newer'? > > > > By definition, "newer" refers to the mtime timestamp. RTFM. > > I did RTFM; you completely missed the point. I don't know if you are > missing it on purpose, but you are still dodging my real question. > You're still saying "well it should use the mtime because the FM says > it uses the mtime". But I'm not talking about the FM. I'm talking > about what people actually use this tool for. People actually use > 'find -newer' to find files which are newer than some given file. > Given that, do you think that it makes sense for this tool to use the > mtime? By definition, a file is newer than another file if its mtime is larger (well, that's the common definition, and I don't think there's a better one -- you could find thousands of definitions of "newer" depending on whether you regard some metadata as significant enough, but the one related to mtime only is the simplest one). So, it makes sense to use the mtime. > > Anyway the fact that "find" has deficiencies does not imply that > > Subversion is allowed to have ones too. > > The reason I brought up find -newer was to ask, _again_, whether you > can think of any reason for the mtime field to exist at all, given that > you don't seem to think it should be interpreted to mean "time of the > file's last modification". *In general*, it's the last time the *contents* were modified. But remember that the filename can change (typically with "mv"), and this is another way to modify a file. > If it doesn't mean that, what in the world does it mean, what is it > useful for? It is useful when it is used correctly (and how to use it correctly depends on the context, e.g. on the file type -- see the use with mbox files, for instance). > Do you see it as just a random extra 32 bits of user-controlled > metadata, to store extra app-specific state on occasion, like with > mboxes? Yes, except that's not random. The exact meaning depends on the context (and that's more a convention that anything else). But the point is that it is a user-accessible field, not a read-only field set by the OS. > > I'm not saying that you should diverge from upstream. When there's a > > bug, it should be fixed upstream too (but as I was using the Debian > > package, I don't always know what is fixed upstream). > > I'll discuss it again with upstream, bringing up the case of 'mv > wc_file_1 wc_file_2', but I have a feeling they're not going to want to > switch to ctime either, even on unix and netware. The mbox case is important too, IMHO. FYI, I've some mbox files in my main Subversion repository. I think that max(mtime,ctime) would be a better solution, but I haven't thought very much about that. -- 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
