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 w
On Thu, Oct 23, 2008 at 5:12 AM, Markus Wanner <[EMAIL PROTECTED]> wrote:
> Thomas Moschny wrote:
>> So, I don't think we should warn there.
>
> Even make hints about clock skews. Why is that so unwanted for monotone?
Make warns about clock skew (between your local host and its NFS
server) because
Hi,
Thomas Moschny wrote:
> Monotone stores timestamps in the date certs in UTC, of course. Nevertheless,
> clocks for each developer might differ a bit such that commits appear to be
> made in non-chronological order.
That's theoretically possible, though pretty rare in practice.
> So, I don'
Hi,
Stephen Leake wrote:
> If there is no global shared clock, then developers working in
> different time zones can easily commit revisions to a shared server
> that have timestamps using local times that appear to be "out of
> order" with respect to each other.
Any sane OS today knows the diffe
Stephen Leake wrote:
> Markus Wanner <[EMAIL PROTECTED]> writes:
> > I'm just proposing to check the date and warn the user if it obviously
> > doesn't match. It would help making that meta-information more reliable,
> > nothing more, nothing less.
>
> If there is no global shared clock, then devel
Markus Wanner <[EMAIL PROTECTED]> writes:
> I'm just proposing to check the date and warn the user if it obviously
> doesn't match. It would help making that meta-information more reliable,
> nothing more, nothing less.
If there is no global shared clock, then developers working in
different time
Hi,
Ethan Blanton wrote:
> That is correct. It actually caused problems for us at some point,
> when something related to monotone started rejecting those fractional
> second values. The oldest revisions in that Pidgin data started out
> as CVS, were migrated to SVN, and then subsequently migrat
Bruce Stephens spake unto us the following wisdom:
> Markus Wanner <[EMAIL PROTECTED]> writes:
> > What surprised me about the pidgin repository is, that there are some
> > date certs with six digits (!) for milliseconds in the date, i.e.:
> > "2006-11-01T21:39:36.807940"
>
> IIRC Tailor did that
Hi,
Daniel Carosone wrote:
> If we're only storing up to seconds, it could happen readily for a
> multi-way merge that created several intermediate merge nodes in the
> one command.
Sure. See the long list of revisions I've posted, there's one such case
within "net.venge.monotone*":
ee293e066a
On Mon, Oct 20, 2008 at 10:49:12AM +0200, Markus Wanner wrote:
> (Yes, this currently includes counting
> dependent revisions with equal timestamps as invalid, which is certainly
> bogus, just highly unlikely).
If we're only storing up to seconds, it could happen readily for a
multi-way merge that
Markus Wanner <[EMAIL PROTECTED]> writes:
[...]
> What surprised me about the pidgin repository is, that there are some
> date certs with six digits (!) for milliseconds in the date, i.e.:
> "2006-11-01T21:39:36.807940"
IIRC Tailor did that at one point, so likely that's a result of
converting
Hi,
as mentioned in other threads already, I'm currently analyzing date
certs and comparing them against the revision ancestry. The obvious
first test database includes all of "net.venge.monotone*" (and nothing
else). At the time of testing, it had 14156 revisions with 17737
relations between them
12 matches
Mail list logo
