Standard behaviour in what context? Certainly not standard behaviour in the
Linux svn client or the Windows svn executable from Collabnet.
Here is what I get in Linux:
david@laptop:~/test$ ls --time-style=full-iso -l
total 4
-rw-r--r-- 1 david david 14 2012-08-03 00:03:49.786793555 -0700 foo
david@laptop:~/test$ svn ci -m "committing"
Sending foo
Transmitting file data .
Committed revision 2.
david@laptop:~/test$ ls --time-style=full-iso -l
total 4
-rw-r--r-- 1 david david 14 2012-08-03 00:03:49.786793555 -0700 foo
david@laptop:~/test$ svn up -r 1
U foo
Updated to revision 1.
david@laptop:~/test$ ls --time-style=full-iso -l
total 0
-rw-r--r-- 1 david david 0 2012-08-03 00:04:13.995662967 -0700 foo
david@laptop:~/test$ svn up -r HEAD
U foo
Updated to revision 2.
david@laptop:~/test$ ls --time-style=full-iso -l
total 4
-rw-r--r-- 1 david david 14 2012-08-03 00:04:25.768085454 -0700 foo
All timestamps are monotonically increasing as it should be. The
~/.subversion/config in Linux says:
### Set use-commit-times to make checkout/update/switch/revert
### put last-committed timestamps on every file touched.
which to me implies that the default is to NOT use commit times on every
file touched.
This might be the culprit in SVNUpdateClient16.java:
if (modified && !special) {
timestamp =
SVNFileUtil.getFileLastModified(adminArea.getFile(fileName));
} else {
timestamp =
SVNDate.parseDateAsMilliseconds(entry.getCommittedDate());
}
...
if (!special && timestamp > 0) {
SVNFileUtil.setLastModified(dstPath, timestamp);
}
I'm guessing that "special" means to use the committed date. I'm not sure
what SVNFileUtil.getFileLastModified(adminArea.getFile(fileName)) is all
about but it somewhat matches what I was seeing, where the timestamp after
updating didn't even match up with any prior commit times, it was some other
time, possible it is this "admin area time".
Dave
Biörnstad, Biörn wrote:
>
> David,
>
> From my experience, this is the standard behaviour. There is an option to
> control this behaviour, though. In your Subversion config file, in the
> [miscellany] section, set the use-commit-times option to yes. SVNKit
> respects the default Subversion config file.
>
> Alternatively, you could provide an ISVNOptions to SVNKit, where you can
> specify your desired behaviour.
>
> Regards,
> Biörn
>
> ________________________________________
> From: svnkit-users-boun...@svnkit.com [svnkit-users-boun...@svnkit.com] on
> behalf of David Grant [davidgr...@gmail.com]
> Sent: 03 August 2012 1:12
> To: svnkit-users@svnkit.com
> Subject: Re: Timestamps not updated to current date/time after update
>
> I've verified this with SmartSVN as well as the jsvn command-line
> front-end
> to SVNkit.
>
> I've confirmed that Collabnet svn.exe for Windows does not behave this way
> (it updates the timestamp to now() on each update regardless), nor does
> svn
> in Linux.
>
>
> David Grant wrote:
>>
>> After doing an update to an older revision, or back to HEAD, the changed
>> files' timestamps are not updated to the current date/time. This wrecks
>> havoc with build systems which rely on timestamps to figure out which
>> files need rebuilding (ie. which source files are newer than targets).
>>
>> Is this expected behaviour? I don't think it is because the svn command
>> line client doesn't do this.
>>
>
> --
> View this message in context:
> http://old.nabble.com/Timestamps-not-updated-to-current-date-time-after-update-tp34247014p34248553.html
> Sent from the SVNKit - Users mailing list archive at Nabble.com.
>
>
>
>
>
--
View this message in context:
http://old.nabble.com/Timestamps-not-updated-to-current-date-time-after-update-tp34247014p34249605.html
Sent from the SVNKit - Users mailing list archive at Nabble.com.
