At 17:11 31-1-2003, Sascha Schumann wrote:
What is the checkout date here?
Let's focus on the real issue. The issue is not which date - it is a means to
asses, which source changes broke/fixed anything.
Something along this line, is looking at the issue, not the indicator:
find . -type f
On Fri, 31 Jan 2003, [iso-8859-1] Kai Schröder wrote:
Hi all,
I'm working on a new framework for analyzing results of make test for QA
Team (see php-qa list).
Talking with Sebastian Nohn, I realized, that we can't differ the versions
in detail. That means, that we can't say which source
I suppose we can have the snapshot generator do that, but it would still
hard to differentiate between CVS versions then.
Sounds a little bit stupid, but why the snapshot generator can't simply
commit a changed /main/php_version.h every 2 hours? The php-cvs mailer
should ignore the commits
On Fri, 31 Jan 2003, Kai Schröder wrote:
I suppose we can have the snapshot generator do that, but it would still
hard to differentiate between CVS versions then.
Sounds a little bit stupid, but why the snapshot generator can't simply
commit a changed /main/php_version.h every 2 hours?
That can be done, but that means 12 commits a day for a single file. I
dont think that's a good idea.
That's true. Now we have round about 30 commits each day. 12 more will make
less than 5.000 blocks (5MB for 1k-blocks) more disk usage per year. Where
do you see the real problem if the commits
I suppose we can have the snapshot generator do that, but it
would still hard to differentiate between CVS versions then.
Sounds a little bit stupid, but why the snapshot generator can't simply
commit a changed /main/php_version.h every 2 hours?
That can be done, but that means 12
Kai Schröder wrote:
That's true. Now we have round about 30 commits each day. 12 more will make
less than 5.000 blocks (5MB for 1k-blocks) more disk usage per year. Where
do you see the real problem if the commits are not mailed to php-cvs list?
that is 12 commits per day to a single file
On Fri, 31 Jan 2003, [ISO-8859-15] Kai Schröder wrote:
That can be done, but that means 12 commits a day for a single file. I
dont think that's a good idea.
That's true. Now we have round about 30 commits each day. 12 more will make
less than 5.000 blocks (5MB for 1k-blocks) more disk
On Fri, 31 Jan 2003, James Aylett wrote:
I suppose we can have the snapshot generator do that, but it
would still hard to differentiate between CVS versions then.
Sounds a little bit stupid, but why the snapshot generator can't simply
commit a changed /main/php_version.h every 2
On Fri, 31 Jan 2003, Kai Schroder wrote:
Sascha found a simple but good solution:
date /CURRENT_TIME
This can be done ... for manual checkouts without
changing source files in cvs.
How is that possible?
Derick
--
Derrick wrote:
date /CURRENT_TIME
This can be done ... for manual checkouts without
changing source files in cvs.
How is that possible?
I don't think it is, because it needs to be done at checkout time, not at
build time.
I previously suggested (with Derrick's reply):
Is the
Sascha found a simple but good solution:
date /CURRENT_TIME
This can be done by snapshot generator and for manual checkouts without
changing source files in cvs. Than /run-tests.php can send the content of
this file with the test results.
Regards, Kai
--
PHP Development Mailing List
How is that possible?
I don't think it is, because it needs to be done at checkout time, not at
build time.
What are you smoking?
That's a one line addition to the snapshot script.
- Sascha, creator, snaps.php.net
--
PHP Development Mailing List http://www.php.net/
To
On Fri, 31 Jan 2003, Sascha Schumann wrote:
How is that possible?
I don't think it is, because it needs to be done at checkout time, not at
build time.
What are you smoking?
That's a one line addition to the snapshot script.
For manual checkouts that has nothing to do
For manual checkouts that has nothing to do with snapshots, so he
isn't smoking anything.
echo test -r CHECKOUT_TIME || date CHECKOUT_TIME buildconf
would be sufficient for that case. It's not perfect, because
it is conceivable that someone does not run buildconf
On Fri, 31 Jan 2003, Sascha Schumann wrote:
For manual checkouts that has nothing to do with snapshots, so he
isn't smoking anything.
echo test -r CHECKOUT_TIME || date CHECKOUT_TIME buildconf
would be sufficient for that case. It's not perfect, because
it is
It's not actually, as we were just trying to *solve* this problem and
prevent getting test results with the wrong date/time.
So what happens if I do this?
cd php4
cvs upd
and a day later do this?
cd php4/ext/standard
cvs upd
What is the checkout date
On Fri, 31 Jan 2003, Sascha Schumann wrote:
It's not actually, as we were just trying to *solve* this problem and
prevent getting test results with the wrong date/time.
So what happens if I do this?
cd php4
cvs upd
and a day later do this?
cd
Hi,
So what happens if I do this?
cd php4
cvs upd
and a day later do this?
cd php4/ext/standard
cvs upd
What is the checkout date here?
I've no idea, do you? I think we just should not allow submissions with
test results if
Sascha:
$ cd php4; cvs upd
and a day later
$ cd php4/ext/standard; cvs upd
What is the checkout date here?
It should be the time of the second update, if anything. Now it /is/
possible to find this out (by getting the most recent modification date of
any CVS control file in the
I've no idea, do you? I think we just should not allow submissions with
test results if they're not made by a snapshot or our phport.sh thingy
for automatic testing.
If that phport.sh thingy reliably ensures the integrity of
the source files, it could work.
Have CVS $Id$'s been
This line will give you the timestamp from the latest
checked in file:
find . -type f|xargs grep '$Id: ' |grep -v Binary |\
sed 's#.*\([12].../../.. ..:..:..\).*#\1#'| sort | tail -1
This should also work with cvs export, does it? Can we add this to build
system as
A very simple solution would simply be to do something like
ls --full-time configure
that allows you to find at what exact time buildconf was used so
pretty much when it was built.
This would be much easier to implement since you don't have to touch CVS
at any time for that... right ?
On Fri,
That can be done, but that means 12 commits a day for a
single file. I
dont think that's a good idea.
Is there some way we can harness CVS keyword subsitutuion in a case like
this?
John
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
24 matches
Mail list logo
