Wesley Leggette wrote:
> On Sun, 2005-08-07 at 14:41 -0400, Ryan Bloom wrote:
>
>>mv and cp are very different under the covers, which is why this is
>>happening. cp always deletes the old file, then it creates a new file
>>with the same name, and copies all of the data. mv, on the other
>>hand, just replaces the name if the files are on the same filesystem.
>>The timestamps for moved files aren't changed.
AFAIK, if you do 'mv FILE1 FILE2' while both are on the same filesystem
and FILE2 exists, then the old FILE2 is deleted and the name of FILE1
is changed to FILE2 (since this means a change in the inode entry, it
changes the "change-time"), everything else is unchanged.
If you do 'cp -p FILE1 FILE2' under the same conditions, the existing
(old) FILE2 is deleted, a new file (with a new inode) is created, all
data from FILE1 is copied into it and then the inode entry of the new
file is fixed up so that the new file has as much of the attributes
of FILE1 as possible. The differences left are the inode number and the
"change-time" (and ownership, unless you are root or you are the owner
anyway). Without '-p', 'cp' creates a new file and copies the data, so
more attributes may be different (ownership, all times, permissions).
>>svn uses the timestamps of files as a clue to determine if it should
>>do more investigation into if the file has changed. This is a
>>performance optimization that svn (and cvs, and most other version
>>control systems) use, because it is much faster to look at timestamps
>>than it is to actually compare content.
*Sigh*... it is faster and sometimes creates wrong results. :-/
>>The easiest work-around, is to just touch the files after you have
>>moved them.
>>... But, why do the moved files have
>>an older timestamp than the files in the .svn directory? Generally,
>>the moved files should have been placed on the filesystem long after
>>your checkout.
If the files to move have not been touched since the checkout, their
timestamps (modification times) are "older", so this should be expected.
>>Can you check the timestamps the next time this happens?
>
>
> Okay, I know for one operation that I did, the files I copied into the
> working copy were much older that the checked out copies, so that would
> make sense for that.
But if the m-times are not *exactly* the same, shouldn't subversion
notice the difference anyway? I thought the algorithm now used is like:
>> stat working and textbase files.
>> if (mtimes of working and textbase are equal):
>> return NOT_CHANGED;
>> else if (filesizes of working and textbase are unequal):
>> return CHANGED;
>> else
>> compare the files byte-by-byte. /* very slow */
Best regards
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 9 15:24:17 2005