subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From xvdes...@gmail.com
Subject Re: Timestamp issue with "svn status" in 1.9.3
Date Thu, 08 Sep 2016 14:40:24 GMT
> 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.

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message