>
> When you 'svn export', you are creating new files, which, naturally
> enough, have both creation and modification dates set to the time
> they're created. Where's the problem?
I wouldn't really call it "naturally", it's just one possible way to
view things. It's the very low level, traditional Unix way of looking
at files - each inode is a separate entity and the system doesn't "care"
how it's been created. Also the "cp" command on my Linux box behaves
this way (the copied file will have a brand new last modification time).
However, the way many users perceive a file is different. If I create
a copy of a file, I would expect that not only the content itself is
duplicated but also some of the meta information, like the last time
when this content has been modified.
This is the way it is handled by Microsoft operating systems (and even
though I'm *not* a big MS lover, this one I find quite nice).
This behaviour is also the default for the KDE file manager Konqueror,
and even the "cp" command has its --preserve switch.
And since subversion can be seen as a versioned file system tree, and
checkout and commit as copy operations in the two directions, I'd
strongly vote for the possibility of keeping the modification date.
>
> Uploading/downloading files from FTP or web servers results in the same
> behaviour. Even copy/move on the local OS can sometimes do the same
> thing.
>
Actually, there exist ftp clients which keep the file modification time
when downloading files.
> Modification dates are fairly useless as a measure of anything
> interesting. It doesn't take a lot to make a file change its date.
Indeed, if someone wants to trick you by manipulating file modification
dates, he can do so very easily.
However, even subversion uses the last modified time to check if a file
has been modified...
just my €0.02
Andreas
Received on Tue Aug 29 10:52:00 2006