It looks like I can't reproduce any funny behaviour in Linux. jsvn and svn behave identically in Linux it seems; however, multiple users are seeing issues in Windows, and I'm sure they and myself have not altered their config files at all, except for perhaps changing global ignores.
Dave Biörnstad, Biörn wrote: > > Dave, > > Sorry, I misread your first message. With "standard behaviour" I referred > to was setting the modification time to the current time (time of update). > That behaviour I have observed at least with TortoiseSVN. > > The 'special' variable you mention is set if the file is a special file > and therefore the timestamp does not matter, see [1]. In my version of > SVNKit (1.3.5), this code is called only by doExport, so it does not apply > when doing an update. > > I know that SVNKit uses the default Subversion client configuration > (~/.subversion/config on Unix) -- but I do not know if the > use-commit-times options is properly adhered to everywhere in the code. I > am currently not using this feature in SVNKit. > > You might want to try specifying your own ISVNOptions, where you can > return false in isUseCommitTimes(). If that is not an option for you and > the option in the config file has no impact, maybe you should file a bug. > > Regards, > Biörn > > [1] http://svnbook.red-bean.com/en/1.7/svn.ref.properties.html > ________________________________________ > From: svnkit-users-boun...@svnkit.com [svnkit-users-boun...@svnkit.com] on > behalf of David Grant [davidgr...@gmail.com] > Sent: 03 August 2012 9:26 > To: svnkit-users@svnkit.com > Subject: RE: Timestamps not updated to current date/time after update > > 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. > > > > > -- View this message in context: http://old.nabble.com/Timestamps-not-updated-to-current-date-time-after-update-tp34247014p34251334.html Sent from the SVNKit - Users mailing list archive at Nabble.com.
