Hi,
Nathaniel Smith wrote:
> Make warns about clock skew (between your local host and its NFS
> server) because such clock skew breaks Make.
Agreed.
> Right now, clock skew (between all the hosts used by everyone in a
> distributed development project) does not break monotone;
This depends on whether you count invalid date certs as breakage or not.
You obviously don't, I do.
> it continues
> to provide its basic functionality of managing revisions just fine.
> Your proposal would compromise this core functionality (either by
> causing revisions to disappear, or just printing annoying warning
> messages), so as 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 understand the impulse,
Phew, good to hear.
> but I don't see how this is the right place
> for it -- if I really want to know about clock skew, there are better
> ways to find out, and if don't have access to those better ways, I can
> just run that script you wrote over my monotone history anyway.
My question is: how do I avoid silly situations like this one here:
# mtn -d $BOTAN_DB log \
> --brief --last=3 \
> --from 1cc7ac30ff0c2871e24e3a76d147cab907b5429e
o 1cc7ac30ff0c2871e24e3a76d147cab907b5429e [EMAIL PROTECTED]
| 2006-09-26T19:33:01 net.randombit.botan
o fb8114127ac9e23c9870bba631a79c41ece29355 [EMAIL PROTECTED]
| 2006-09-27T03:44:57 net.randombit.botan
o 3c74c0b06690f73b9d34435e77432e6776c1f7e3 [EMAIL PROTECTED]
2006-09-27T01:29:54 net.randombit.botan
Why does monotone show a date at all, if it's so unreliable, unchecked
and not considered "core functionality" by monotone?
Anyway, I think there's enough resistance to drop the idea for now.
Regards
Markus Wanner
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
