Aah, much better.
Build Warnings ----- -------- 285 46 284 518 283 518 281 518 ... ...
(Btw, why is build 286 displayed before build 285 in the overview?)
(Btw, why is build 286 displayed before build 285 in the overview?)
It probably has something to to with that they seem to have the same timestamp.
/ Peter Bortas
Previous text:
2002-11-19 00:07: Subject: Warning.... warning....
Aah, much better.
Build Warnings
285 46 284 518 283 518 281 518 ... ...
(Btw, why is build 286 displayed before build 285 in the overview?)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Yes, but since the build number is monotonous, why bother comparing the dates?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-11-19 00:11: Subject: Warning.... warning....
(Btw, why is build 286 displayed before build 285 in the overview?)
It probably has something to to with that they seem to have the same timestamp.
/ Peter Bortas
I'm just as happy it does. Two builds on the same second sounds like a bug to me, so this way we noticed it. :-)
/ Peter Bortas
Previous text:
2002-11-19 00:15: Subject: Warning.... warning....
Yes, but since the build number is monotonous, why bother comparing the dates?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
The bug was that when you ran a forced build it used the latest checkin as its timestamp.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-11-19 00:18: Subject: Warning.... warning....
I'm just as happy it does. Two builds on the same second sounds like a bug to me, so this way we noticed it. :-)
/ Peter Bortas
I'll take back my bug accusation then. That sounds like a possible visualisation misfeature, but not really a bug.
/ Peter Bortas
Previous text:
2002-11-19 00:27: Subject: Warning.... warning....
The bug was that when you ran a forced build it used the latest checkin as its timestamp.
/ Martin Nilsson (Fake Build Master)
Well, there was a bug, but not in the far backend. Two builds should never have the same build time stamp.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-11-19 00:29: Subject: Warning.... warning....
I'll take back my bug accusation then. That sounds like a possible visualisation misfeature, but not really a bug.
/ Peter Bortas
We're shaking out the bugs that came along with changing the meaning of the timestamps. The timestamp used to mean "the time when the build finished" before. Now it is what you would feed to cvs -D to check out or update your pike tree to make an equivalent pike build from the same source base as the pikefarm build.
The time is still reported in CET in the UI for now, though. People living in other time zones have to convert the time to their own time zone (if anyone knows of a way to feed cvs UTC time I'd be interested to know how for a docs page I'm planning).
/ Johan Sundström (ärkehertig av Lysators rootgrupp)
Previous text:
2002-11-19 00:18: Subject: Warning.... warning....
I'm just as happy it does. Two builds on the same second sounds like a bug to me, so this way we noticed it. :-)
/ Peter Bortas
In the last episode (Nov 19), Johan Sundstrm (rkehertig av Lysators rootgrupp) @ Pike (-) developers forum said:
We're shaking out the bugs that came along with changing the meaning of the timestamps. The timestamp used to mean "the time when the build finished" before. Now it is what you would feed to cvs -D to check out or update your pike tree to make an equivalent pike build from the same source base as the pikefarm build.
The time is still reported in CET in the UI for now, though. People living in other time zones have to convert the time to their own time zone (if anyone knows of a way to feed cvs UTC time I'd be interested to know how for a docs page I'm planning).
CVS already stores timestamps in UTC, both in the cvs repo and in stuff like "cvs log" output and $Id$.
In the last episode (Nov 18), Dan Nelson said:
The time is still reported in CET in the UI for now, though. People living in other time zones have to convert the time to their own time zone (if anyone knows of a way to feed cvs UTC time I'd be interested to know how for a docs page I'm planning).
CVS already stores timestamps in UTC, both in the cvs repo and in stuff like "cvs log" output and $Id$.
.. and for feeding it UTC time with -D, tell it the timezone: ' cvs update -D "2002-11-15 12:34:56 UTC" ' should work. The manpage example has "GMT", but "UTC" should work too.
CVS already stores timestamps in UTC, both in the cvs repo and in stuff like "cvs log" output and $Id$.
Yep, knew that. :)
.. and for feeding it UTC time with -D, tell it the timezone: ' cvs update -D "2002-11-15 12:34:56 UTC" ' should work. The manpage example has "GMT", but "UTC" should work too.
Ah, just what I was looking for! Thanks.
/ Johan Sundström (ärkehertig av Lysators rootgrupp)
Previous text:
2002-11-19 06:31: Subject: Re: Warning.... warning....
In the last episode (Nov 18), Dan Nelson said:
The time is still reported in CET in the UI for now, though. People living in other time zones have to convert the time to their own time zone (if anyone knows of a way to feed cvs UTC time I'd be interested to know how for a docs page I'm planning).
CVS already stores timestamps in UTC, both in the cvs repo and in stuff like "cvs log" output and $Id$.
.. and for feeding it UTC time with -D, tell it the timezone: ' cvs update -D "2002-11-15 12:34:56 UTC" ' should work. The manpage example has "GMT", but "UTC" should work too.
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Dan Nelson -
Johan Sundstr�m (�rkehertig av Lysators rootgrupp) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (Fake Build Master) ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum