regression test report time
Hi testers, is it at all possible to localize the "time" of the reports to GMT? I'm trying to clean up the mess introduced by the replacement of the old numeric_cast with the new one, but I just can't see if a given test report is current or not (i.e, was run after I commit) TIA Fernando Cacciola SciSoft
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Fernando Cacciola writes:
Hi testers, is it at all possible to localize the "time" of the reports to GMT?
? Everything in the reports is already normalized to UTC.
That's a little hard to reconcile with what I'm seeing up there. For example, RudbekAssociates Sat, 25 Jun 2005 22:00:03 +0000 I'm pretty sure this has been up there since at least this morning my time, and is clearly a few days out-of-date, showing: Test output: RudbekAssociates - iterator - filter_iterator_test / vc-8_0 Report Time: Sun, 26 Jun 2005 00:49:23 +0000 Compiler output [2005-06-25 23:46:48 UTC]: CALL "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\bin\vcvars32.BAT" >nul "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\bin\cl" /Zm800 -nologo /EHsc -c /Z7 /Od /Ob0 /EHsc /GR /MDd /Zc:forScope /Zc:wchar_t -I"C:\Projects\results\bin\boost\libs\iterator\test" -I"C:\Projects\boost" -Fo"C:\Projects\results\bin\boost\libs\iterator\test\filter_iterator_test.test\vc-8_0\debug\threading-multi\filter_iterator_test.obj" -Tp"..\libs\iterator\test\filter_iterator_test.cpp" filter_iterator_test.cpp C:\Projects\boost\boost/mpl/numeric_cast.hpp : error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format This is a problem Doug fixed before Fri, 24 Jun 2005 08:59:49 -0500 while metacomm Sat, 25 Jun 2005 13:01:03 +0000 Just appeared and appears to be consistent with recent checkins. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Fernando Cacciola writes:
Hi testers, is it at all possible to localize the "time" of the reports to GMT?
? Everything in the reports is already normalized to UTC.
That's a little hard to reconcile with what I'm seeing up there. For example,
RudbekAssociates Sat, 25 Jun 2005 22:00:03 +0000
I'm pretty sure this has been up there since at least this morning my time, and is clearly a few days out-of-date, showing:
Test output: RudbekAssociates - iterator - filter_iterator_test / vc-8_0 Report Time: Sun, 26 Jun 2005 00:49:23 +0000
Compiler output [2005-06-25 23:46:48 UTC]:
CALL "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\bin\vcvars32.BAT" >nul "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\bin\cl" /Zm800 -nologo /EHsc -c /Z7 /Od /Ob0 /EHsc /GR /MDd /Zc:forScope /Zc:wchar_t -I"C:\Projects\results\bin\boost\libs\iterator\test" -I"C:\Projects\boost" -Fo"C:\Projects\results\bin\boost\libs\iterator\test\filter_iterator_test.test\vc-8_0\debug\threading-multi\filter_iterator_test.obj" -Tp"..\libs\iterator\test\filter_iterator_test.cpp"
filter_iterator_test.cpp C:\Projects\boost\boost/mpl/numeric_cast.hpp : error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format
This is a problem Doug fixed before Fri, 24 Jun 2005 08:59:49 -0500
The only reasonable explanation I have for this is that Victor's results are somehow run against the old sources. -- Aleksey Gurtovoy MetaCommunications Engineering
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> escribió en el mensaje news:m17jghu6i4.fsf@tulip.office.meta...
David Abrahams writes:
Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:
Fernando Cacciola writes:
Hi testers, is it at all possible to localize the "time" of the reports to GMT?
? Everything in the reports is already normalized to UTC.
That's a little hard to reconcile with what I'm seeing up there. For example,
RudbekAssociates Sat, 25 Jun 2005 22:00:03 +0000
I'm pretty sure this has been up there since at least this morning my time, and is clearly a few days out-of-date, showing:
Test output: RudbekAssociates - iterator - filter_iterator_test / vc-8_0 Report Time: Sun, 26 Jun 2005 00:49:23 +0000
Compiler output [2005-06-25 23:46:48 UTC]:
CALL "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\bin\vcvars32.BAT" >nul "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\..\..\VC\bin\cl" /Zm800 -nologo /EHsc -c /Z7 /Od /Ob0 /EHsc /GR /MDd /Zc:forScope Zc:wchar_t -I"C:\Projects\results\bin\boost\libs\iterator\test" -I"C:\Projects\boost" -Fo"C:\Projects\results\bin\boost\libs\iterator\test\filter_iterator_test.test\vc-8_0\debug\threading-multi\filter_iterator_test.obj" -Tp"..\libs\iterator\test\filter_iterator_test.cpp"
filter_iterator_test.cpp C:\Projects\boost\boost/mpl/numeric_cast.hpp : error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format
This is a problem Doug fixed before Fri, 24 Jun 2005 08:59:49 -0500
Precisely, that is why I eventually thought the test were not UTC synchronized (plus the small fact that there is no "UTC" ot "GMT" label in the reports)
The only reasonable explanation I have for this is that Victor's results are somehow run against the old sources.
That or I am still somnehow commiting Mac sources!! I had used boost inspect before commiting (with the -crlf option) and the only file reported is the one in inspect used precisely to show this, so I'm sure I had no such files _before_ commiting. I use TortoiseCVS, and it has options named "Check not Unix sandbox" and "Use Unix line endings", which are Unchecked and Checked respectively. But these options are not supposed to cause such problems, so if I am commiting Mac files I can't see how. Fernando Cacciola SciSoft
Fernando Cacciola wrote:
That or I am still somnehow commiting Mac sources!!
I had used boost inspect before commiting (with the -crlf option) and the only file reported is the one in inspect used precisely to show this, so I'm sure I had no such files _before_ commiting.
Good :-) But it usually shows up after one commits, and another updates, not before the commit.
I use TortoiseCVS, and it has options named "Check not Unix sandbox" and "Use Unix line endings", which are Unchecked and Checked respectively. But these options are not supposed to cause such problems, so if I am commiting Mac files I can't see how.
Did you really mean: "Check not Unix sandbox" *off* "Use Unix line endings" *on* Because if you did, that second one is precisely what's causing the problem. If your files have DOS EOLs you can't tell *CVS that you have Unix EOLs. By the way I also use TCVS (and WinCVS) and I don't have those options. I have a single "Sandbox DOS/UNIX:" which I set to "Autodetect (default to DOS)". Works without problems. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
"Rene Rivera" <grafik.list@redshift-software.com> escribió en el mensaje news:42C0367B.2080907@redshift-software.com...
Fernando Cacciola wrote:
That or I am still somnehow commiting Mac sources!!
I had used boost inspect before commiting (with the -crlf option) and the only file reported is the one in inspect used precisely to show this, so I'm sure I had no such files _before_ commiting.
Good :-) But it usually shows up after one commits, and another updates, not before the commit.
I use TortoiseCVS, and it has options named "Check not Unix sandbox" and "Use Unix line endings", which are Unchecked and Checked respectively. But these options are not supposed to cause such problems, so if I am commiting Mac files I can't see how.
Did you really mean:
"Check not Unix sandbox" *off* "Use Unix line endings" *on*
Hmmm, yes...
Because if you did, that second one is precisely what's causing the problem. If your files have DOS EOLs you can't tell *CVS that you have Unix EOLs.
Oh well, from its "tool-tip" (its only help), which refers to the "checkout" command, I really interpreted that as _just_ meaning that files with Unix EOLs are/aren't converted to DOS into my local HD (just like my editor(s) would/wouldn't do); but I never thought it would mess up with the commit.
By the way I also use TCVS (and WinCVS) and I don't have those options. I have a single "Sandbox DOS/UNIX:" which I set to "Autodetect (default to DOS)". Works without problems.
Ha, you might have a new version.. I'll check it out. BTW, I most likely introduced the problem again. So I re-commited (with the second check turned off). I hope it fixes the problem now (for good). Best Fernando Cacciola SciSoft
participants (4)
-
Aleksey Gurtovoy -
David Abrahams -
Fernando Cacciola -
Rene Rivera