[Monotone-devel] Re: date certs on net.venge.monotone
Markus Wanner wrote: to better provide the functionality of letting people know that someone else's clock that they can't fix is broken. The main motivation is making dates cert information more reliable. But it looks like that's not considered core functionality of monotone. I think Nathaniel's point of you can't fix is important… let's exemplify it: day 1. user NTP commits with correct date 2008-10-24 day 2. user MadTime commits with incorrect date 2009-10-25 (and you can do nothing about it, as it's incorrect in the future, so the check you propose would happily pass) day 3. user NTP tries to commit with correct date 2008-10-26 gets a warning he can do nothing about as it wasn't his fault really Being user NTP I would in fact be bothered by that warning… if we could devise a way to warn user Madtime and not user NTP, I'd happily choose for it, but I can't see a way myself… OK, in my exaggerated +1year case you could use a are you sure to commit on a 1-year-old branch warning, but in more mundane +1day cases that wouldn't be nice at all. -- Lapo Luchini - http://lapo.it/ “When two trains approach each other at a crossing, both shall come to a full stop and neither shall start up again until the other has gone.” (Kansas State Legislature) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: date certs on net.venge.monotone
Markus Wanner [EMAIL PROTECTED] writes: [...] The main motivation is making dates cert information more reliable. But it looks like that's not considered core functionality of monotone. I don't think anyone objects on principle. The question is just of whether it's possible to do that in a cost-effective way. [...] Why does monotone show a date at all, if it's so unreliable, unchecked and not considered core functionality by monotone? Because (presumably) it's useful, even though it's not as reliable as you might like. I note that (AFAIK) no other VCS verifies dates either, and they all still keep them. And emails regularly contain incorrect dates, but dates are still on the whole useful. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: date certs on net.venge.monotone
Hi, Bruce Stephens wrote: Because (presumably) it's useful, even though it's not as reliable as you might like. I note that (AFAIK) no other VCS verifies dates either, and they all still keep them. And emails regularly contain incorrect dates, but dates are still on the whole useful. Agreed. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: date certs on net.venge.monotone
Hi, Lapo Luchini wrote: I think Nathaniel's point of you can't fix is important… let's exemplify it: One can always distrusting invalid information. Currently this involves distrusting the whole revision, but that doesn't necessarily have to be bound together. mtn could easily provide a command to re-certify a revision with a sane date, for example. day 1. user NTP commits with correct date 2008-10-24 day 2. user MadTime commits with incorrect date 2009-10-25 (and you can do nothing about it, as it's incorrect in the future, so the check you propose would happily pass) day 3. user NTP tries to commit with correct date 2008-10-26 gets a warning he can do nothing about as it wasn't his fault really # mtn pull madtime.badhost.com ... WARNING: rev XY is certified to be from the future (or your system's clock is out of sync). ... # date-- checking against wrist-watch # mtn cert XY date `date -u +%Y-%M-%dT%H:%M:%S` Of course, that gets pretty tedious when multiple revisions are involved. But that's a question of good or bad UI, not one of internal workings and checking. And it would require policy branches to be anywhere close to usable. So, yes, at the moment it would involve unwanted UI uglification. So I'm postponing this proposal until we have policy branches :-) Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: date certs on net.venge.monotone
Stephen Leake wrote: TAI might be a better global time choice, since it doesn't do leap seconds, and hence is monotonic. Duh! Isn't UTC monotonic as well, even if it sometimes changes speed? AFAIR leap seconds mean a minute with either 59 or 61 seconds, nothing never jumps ahead or behind… but I should probably refresh my UTC a bit. OTOH TAI seems nice and good and has an official 64 bit representation; DJB wrote a (now public-domain) library for it too: http://cr.yp.to/libtai.html -- Lapo Luchini - http://lapo.it/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: date certs on net.venge.monotone
Thomas Moschny wrote: Why would you want to warn about that? So, I don't think we should warn there. My opinion regarding that warning depends on the offset: of course something up to a few minutes delta means nothing (simply the user didn't care use NTP), a delta up to one day means little (the user didn't configure the timezone), but a delta over one day is wrong for sure… I'm sure a warning would be nice to have in that last case, but probably also in the middle one. For me, I'd like a warning also in the first case (I'm an NTP-freak), but I would never suggest an option to change its behaviour, clutters the UI more that acceptable for what it gives, IMHO… -- Lapo Luchini - http://lapo.it/ “I do engineering, not religion.” (Daniel J. Bernstein) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
