monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] date certs on net.venge.monotone


From: Markus Wanner
Subject: Re: [Monotone-devel] date certs on net.venge.monotone
Date: Fri, 24 Oct 2008 10:34:34 +0200
User-agent: Thunderbird 2.0.0.16 (X11/20080916)

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 address@hidden
|   2006-09-26T19:33:01 net.randombit.botan
o   fb8114127ac9e23c9870bba631a79c41ece29355 address@hidden
|   2006-09-27T03:44:57 net.randombit.botan
o   3c74c0b06690f73b9d34435e77432e6776c1f7e3 address@hidden
    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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]