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

[Markus Wanner]

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 migrated to
> Monotone.  There's plenty of weird and wonderful-ness in there.  ;-)

Aha, thanks for confirmation.

> Which brings me to a (yet another) reason that I don't think this
> mucking about with date certs is a good idea -- there are almost
> certainly *correct* date certs in the Pidgin repository which are out
> of order.

I'm not sure what you mean be *correct* dates certs being out of order.
I've counted exactly 36 discrepancies in the pidgin repository, see my
mail starting this thread:

> pidgin: 36 of 28349 (0.13%)

> During our migration, there were a number of revisions
> which, for one reason or another, had problems which made them
> difficult to migrate (svn is capable of creating revisions under
> normal circumstances which it cannot subsequently handle gracefully).

Yeah, svn is capable of doing lots of nasty things...

> There are sequences of such revisions which were collapsed to one
> "patch-up" revision in the migration; the date stamp on the patch-up
> revision is the date of its creation, not the date of the original
> changes.  This causes one date in the middle of a sequence of valid
> revisions to be months or even years newer than its ancestors or
> descendants.

Agreed.

> Generally speaking, date information in monotone is very much
> meta-information.  Introducing the idea of global clocks in this
> manner takes it from being meta-information to being revision
> information.

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.

> I think this is a bad idea.  If I've had a patch sitting
> on my disk for 2 months, and I just now get around to committing it,
> it may be a reasonable and correct thing for me to want to do to use a
> --date argument to the commit of the creation of the patch, not the
> commit of the patch.

In that case you should certainly also commit against the parent
revision you've created the patch against. So that would not result in
timestamp inconsistencies.

> I guess, basically, I'm not a fan of validating anything for
> consistency which does not have a clear definition of consistency.  In
> the absence of global clocks, dates do not have consistency.  The fact
> that monotone currently recognizes and ignores this information is a
> feature, not a bug.

Monotone does not ignore the information, but create date certs from it.
Ignoring it would mean dropping date certs entirely.

Please keep in mind that for us human beings there *is* a global clock
and we like to express ourselves in terms of date and time. Of course,
monotone cannot rely on the system clock being in sync with the global
clock. But as pointed out, the assumption is good enough to provide that
convenience feature called "date cert".

To help the user making that convenience feature more reliable, it would
help if monotone checked date certs, IMO, without hurting anything else.

Regards

Markus Wanner