|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [JIRA] (JENKINS-13671) Accurev cannot sy... [email protected] (JIRA)
- [JIRA] (JENKINS-13671) Accurev cann... [email protected] (JIRA)
- [JIRA] (JENKINS-13671) Accurev cann... [email protected] (JIRA)
- [JIRA] (JENKINS-13671) Accurev cann... [email protected] (JIRA)
- [JIRA] (JENKINS-13671) Accurev cann... [email protected] (JIRA)
- [JIRA] (JENKINS-13671) Accurev cann... [email protected] (JIRA)
- [JIRA] (JENKINS-13671) Accurev cann... [email protected] (JIRA)
- [JIRA] (JENKINS-13671) Accurev cann... [email protected] (JIRA)

One gets similar problems on Windows Vista & Windows 7 etc (any version with UAC) - only an admin (or root) user can set the time - accurev's solution was only a cludge to workaround clock problems when there's no decent network service available, which is highly unlikely these days.
The solution I used was to keep the slaves clocks' in sync with the server using the Windows Time Service (which requires a lot of registry settings to convince it to stay within a second or 3 of the server's time, but is possible).
Users who have unix could use ntpd to much better effect (as ntpd is much better than WTS, as it can easily keep within a few milliseconds of the server's time, rather than struggling to stay within a few seconds) and that has a far less disruptive effect than setting the time.
The proposed fix would be an improvement to the plugin, but I don't think that fixing accurev's synctime feature is the solution to the underlying problem - a better solution is not to need accurev's feature![]()