Re: [Boost-testing] revisions and timestamps

Subject: Re: [Boost-testing] revisions and timestamps
From: Daniel James (dnljms_at_[hidden])
Date: 2014-01-19 19:07:39

On 19 January 2014 22:57, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
> Le 19/01/14 19:47, Joaquin M Lopez Munoz a écrit :
>
>> Now that regression testers go against Github, the reported revision # is
>> a
>> bunch of random hexadecimal digits (for instance, "rev 29e219") rather
>> than
>> an increasing number like in SVN, which makes it very hard to determine at
>> a
>> glance if a particular test pre- or postdates a revision one's interested
>> in.
>>
>> I see also that the reported timestamp, which looks like
>>
>>   "Sun, 19 Jan 2014 06:08:04 +0000"
>>
>> seems to indicate the time where the result file was generated, which is
>> of little use. Woukd it be hard to adapt the scripts so that the reported
>> date is instead that associated to the revision? Is this info available to
>> the regression tester? The change, if possible, would render regression
>> tables much more usable.
>>
>>
> Hi Joaquin,
>
> I suspect that the situation is even worst. I have the impression that the
> date associated to a revision corresponds to the date the revision was
> committed locally, not when it was pushed to develop or master. Can some of
> the Git experts confirm my suspicion?

The date would be from the super project. Updates to use the latest
version of a module are automated and pushed almost immediately after
a commit, so the dates for automatic commits should be reliable.

There might be a little confusion if someone has made manual changes
to the super project. One thing we could do is use the committer date,
rather than the author date. This means that if a change is committed
after it was originally made (e.g. by cherry-picking) the date of the
commit is used, rather than the original date. Even if this is pushed
a while after the commit, the date would be fine for comparing with
other dates in the history - since a push must include a commit that
was made after the current commit on github (unless it's forced, but
the tested branches super project should never have a forced push).
Merges might be tricky to interpret, but generally it shouldn't be
problematic.

And we want to move as many files as possible out of the super
project, so that there should be less manual changes in the future.

We can get the committer date for a revision using:

git show --pretty="format:%cd" --no-patch HEAD

(HEAD can be replaced with the hash or whatever), although I wouldn't
be surprised if there's a better way to do that.I guess this would
have to be done in the python scripts and would need to deal with
timezones.