> 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.
Received on 2016-09-09 01:23:43 CEST