> So, that's why you're seeing this behaviour. What's unclear is why you are > investigating this behaviour in the first place. What is your use case for > changing the file's content but leaving it's timestamp unchanged?
We have a very clear case for this. An automated Jenkins process must extract a set of files from SVN and "merge" them in some way, and check in the result somehwere else. This process checks outs the source data and the target location, then performs the merge. The a post-build action tries to commit the resulting merged file. When only 1 byte is changed in a source file, the resulting merged file does not change in length. And as this is an automated process, the merge script is so fast that the commit occurs within the same timestamp as the checkout. I believe the timestamp to have a granularity of minutes on Linux, but I'm not sure of this. Even if it has second precision, such merge scripts can beat that. In bash code, we can easily add the use-commit-times option. But when using the SVN plugin in Jenkins, you cannot pass extra options like this one unless you change de default settings of the account. It would be very nice if a simple flag upon commit or status would allow to force a checksum check rather than a timestamp/filesize check. Rsync is an example that does this with the --checksum option.
