Re: Push timestamps

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Thu, Oct 31, 2019 at 11:07:30AM +0200, Andreas Gustafsson wrote:
> It has come to my attention that Mercurial does not keep track of when
> changes appear in the public repository.  The commit timestamp only
> indicates when a change was initially committed in the developer's
> local repository, which could be months before it appears in -current
> (or some other public branch), especially when rebasing is involved.
> From the parental lineage of the commits, you may be able to determine
> the order in which the commits appeared, but not the date and time
> when they did so.

Time stamps are part of a commit's meta data. They are under full
control of the commiter. That's a general property pretty much any
DVCS share. A DVCS can also not really keep track of when a given commit
"became" visible in the normal model because that would by nature
require changing the commit.

> This means that the Mercurial repository does not contain all the
> information needed to generate reports showing the evolution of
> -current on a calendar timeline, such as those generated from CVS at
> http://releng.netbsd.org/b5reports/i386/.  It also means you can't
> answer questions such as "when was this bug fixed in -current?" with
> a date and time based only on the information in the repository.

A calendar timeline is fundamentally broken as concept for a DVCS. We
avoid some of the issues by restricting merge commits, but the general
problem remains. It is also very much the wrong question answer. The way
to answer that is by a given commit identifier and not using a
timestamp.

> The Mozilla project has a Mercurial extension called "pushlog" which
> looks like it could provide the missing information:
> 
>   https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/pushlog.html

FYI, we have pushlog enabled for other reasons on hgmaster, but it is
currently not getting replicated to anonhg.

Joerg