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.



Reply via email to