Quoth Jan Hendrik <mailto:jan.hendrik@myrealbox.com>:
>> This behavior does exist in Subversion, but I do not believe it is
>> considered a bug. Rather, I believe it is considered a user error to
>> modify a file but not update its timestamp.
>
> A timestamp reset to an earlier date should be considered even
> more a user error then, but SVN will happily commit then. At least
> SVN should provide a --force switch to have it compare ALL files in
> WC with base, no matter what timestamps say.
Actually no, it won't commit then. At least not if there aren't any
actual changes.
The timestamp thing is actually a *feature* of SVN, not a bug. It's a
performance optimisation, since it's a lot easier and faster to check
the timestamps of files than to check their contents.
Essentially, when scanning the directory SVN will first obtain a list of
all files whose timestamps are different from what it was expecting. It
then scans the *contents* of those files having a different timestamp to
see if the actual file contents have changed (by doing a hash of some
kind, probably an MD5, but I'm not sure of the exact details). Only
those files which have both a different timestamp and a different
checksum will be considered "modified" and will be committed.
You can test this easily yourself -- from a pristine unmodified (but
versioned) file, make a change and save it. Do "svn st" and note the
file is listed as modified. Now edit the file again and remove the
change you just made. Do another "svn st" and the file will no longer
be listed (because it's no longer considered modified, even though its
timestamp differs).
If it scanned the contents of all files then the update/commit process
would be at least an order of magnitude slower than it already is.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 14 00:10:49 2007