5 messages, 4 authors, 2002-01-16 · open the first message on its own page
From: Larry McVoy <hidden>
Date: 2002-01-15 19:22:33
IOW, check that your clock is not borked before committing changesets...
Would you like me to make you a "pre-commit" trigger which catches these problems? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Tom Rini <hidden>
Date: 2002-01-15 20:57:55
On Tue, Jan 15, 2002 at 11:22:33AM -0800, Larry McVoy wrote:
Would you like me to make you a "pre-commit" trigger which catches these problems?
If you've got the time, sure. Hopefully we're all done breaking our clocks tho. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden>
Date: 2002-01-16 11:28:53
On Tue, 15 Jan 2002, Tom Rini wrote:
On Tue, Jan 15, 2002 at 11:22:33AM -0800, Larry McVoy wrote:quoted
Would you like me to make you a "pre-commit" trigger which catches these problems?If you've got the time, sure. Hopefully we're all done breaking our clocks tho. :)
Never underestimate the capability of people to screw up, seven something as trivial as the clock ;-) Regards, Gabriel. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gavin Hemphill <hidden>
Date: 2002-01-16 15:30:19
Couldn't the pre-trigger actually check with an ntp server at the bk end and put up a warning if the commit times are off by "too much". Tom Rini wrote:
On Tue, Jan 15, 2002 at 11:22:33AM -0800, Larry McVoy wrote:quoted
Would you like me to make you a "pre-commit" trigger which catches these problems?If you've got the time, sure. Hopefully we're all done breaking our clocks tho. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden>
Date: 2002-01-16 18:59:33
On Wed, 16 Jan 2002, Gavin Hemphill wrote:
Couldn't the pre-trigger actually check with an ntp server at the bk end and put up a warning if the commit times are off by "too much".
It is simpler to have the clock of the server be phase-locked on an NTP server. I don't know where the bk servers are located but they almost certainly have an NTP server within 100ms RTT (round-trip time). If paranoid, the pre-trigger script could even refuse any changeset as long as the local clock is not phase-locked, i.e., during the first few minutes after a reboot (however the ntpdate <time-server-host> which is performed normally during boot scripts to initially set the clock before starting the NTP daemon should be more than sufficient). Besides that, this is a good idea, it should only check the timestamp on the Changeset is not in the future (bk already ensures that timestamps ordering in the graph of changesets). A time well in the past is acceptable since a changeset or set of changesets can be pushed well after being done in a private tree. After this, a developer with a bad clock can either wait to push (if it's only a few minutes or hours in the future) or undo and redo his changeset(s) if his/her clock was far too much in advance. Regards, Gabriel. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/