From: Larry McVoy <hidden> Date: 2002-01-15 21:02:03
What I was thinking was one of two approaches:
a) try and connect to a well known time server and see if the time is too
far off at commit time. May or may not work.
b) see if the time is "too different" from the last changeset. Most trees
are fairly active and if the time is too far ahead (say a month?), then
raise a warning and ask the user to confirm this is the correct time.
Comments?
On Tue, Jan 15, 2002 at 01:57:55PM -0700, 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/
On Tue, Jan 15, 2002 at 01:02:03PM -0800, Larry McVoy wrote:
a) try and connect to a well known time server and see if the time is too
far off at commit time. May or may not work.
This would require some external program tho, wouldn't it?
b) see if the time is "too different" from the last changeset. Most trees
are fairly active and if the time is too far ahead (say a month?), then
raise a warning and ask the user to confirm this is the correct time.
From: Gabriel Paubert <hidden> Date: 2002-01-16 11:37:03
On Tue, 15 Jan 2002, Larry McVoy wrote:
What I was thinking was one of two approaches:
a) try and connect to a well known time server and see if the time is too
far off at commit time. May or may not work.
While there are NTP servers all around the globe (and I maintain the one
we have here at work), finding the nearest one is not always easy.
Furthermore some people may create a changeset while disconnected on a
laptop or would object the cost of an additional call just to get the
time.
b) see if the time is "too different" from the last changeset. Most trees
are fairly active and if the time is too far ahead (say a month?), then
raise a warning and ask the user to confirm this is the correct time.
Probably better, although I like the a) solution because it is likely to
be more exact. AFAIK the bk variables in the usr home directory only
affect the GUI Tools look and feel, it would be too much a stretch to add
a time server specification, no ?
Regards,
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2002-01-16 11:39:58
On Tue, 15 Jan 2002, Tom Rini wrote:
On Tue, Jan 15, 2002 at 01:02:03PM -0800, Larry McVoy wrote:
quoted
a) try and connect to a well known time server and see if the time is too
far off at commit time. May or may not work.
This would require some external program tho, wouldn't it?
It's called ntpq, and I believe most people should have it installed, even
if they don't go to full ntpd synchornisation. Besides that, the NTP
protocol is very simple, especially if you don't care about round trip
time measurement: it's UDP (on port 123 AFAIR).
quoted
b) see if the time is "too different" from the last changeset. Most trees
are fairly active and if the time is too far ahead (say a month?), then
raise a warning and ask the user to confirm this is the correct time.
I'd say 'b' with an override option (yes, the clock IS fine, the tree
has just been dead for awhile).
Probably the best solution indeed...
Regards,
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Wed, Jan 16, 2002 at 12:39:58PM +0100, Gabriel Paubert wrote:
On Tue, 15 Jan 2002, Tom Rini wrote:
quoted
On Tue, Jan 15, 2002 at 01:02:03PM -0800, Larry McVoy wrote:
quoted
a) try and connect to a well known time server and see if the time is too
far off at commit time. May or may not work.
This would require some external program tho, wouldn't it?
It's called ntpq, and I believe most people should have it installed
[snip]
Should doesn't mean they will tho. :) And the first time you assume
everyone has something, 5 people pop up screaming 'cuz they don't.
--
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:43:39
On Wed, 16 Jan 2002, Tom Rini wrote:
On Wed, Jan 16, 2002 at 12:39:58PM +0100, Gabriel Paubert wrote:
quoted
On Tue, 15 Jan 2002, Tom Rini wrote:
quoted
On Tue, Jan 15, 2002 at 01:02:03PM -0800, Larry McVoy wrote:
quoted
a) try and connect to a well known time server and see if the time is too
far off at commit time. May or may not work.
This would require some external program tho, wouldn't it?
It's called ntpq, and I believe most people should have it installed
[snip]
Should doesn't mean they will tho. :) And the first time you assume
everyone has something, 5 people pop up screaming 'cuz they don't.
No, but as I said, the protocol is trivial if you want a very approximate
time (use NTP v3 since all V4 servers I know support it). The problem is
finding the closest server, not sending an UDP packet and decoding the
answer and giving up if you don't receive anything after 5 packets or so.
I'm almost certain there is database of servers somewhere, but I just
don't remember where (between 2 cesium clocks, one hydrogen maser, 2 GPS
and one radio receiver I have enough references for my use at the
telescope ;-)). I also don't know whether some people could be blocked
from using NTP, but I don't think that it is a satisfactory solution in
any case.
Regards,
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Paul Mackerras <hidden> Date: 2002-01-17 01:10:23
Larry McVoy writes:
What I was thinking was one of two approaches:
a) try and connect to a well known time server and see if the time is too
far off at commit time. May or may not work.
Are you talking about doing this just on ppc.bkbits.net or on
everybody's repository clone as well? I think it would be an
excellent idea for ppc.bkbits.net to reject changesets whose time is
after the current time. I don't think we want to make everybody's
clones do that though.
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/