RE: [PHP-DEV] RfC: version names

2003-02-01 Thread Melvyn Sopacua
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 -name *.[chy] -print | xargs grep '/\*[[:space:]]*\$Id:' 
|sed -e s|^[^:]*:|| CVSIDS

This should be in run-tests.php, or a seperate script even, to allow you to 
track down
build breakers.

It would be required that all source files, have a conforming header so 
this has an
extra bonus.

With kind regards,

Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RfC: version names

2003-01-31 Thread Derick Rethans
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 packet was used to
 build php. Is there any way to name the versions 4.3.0 (release), 4.3.1-dev
 (taken from cvs, additional timestamp would be nice), 4.3.1-snapMMDDHHii
 (taken from snaps.php.net) and 4.3.1-win32-snapMMDDHHii (Win32
 Snapshot)?

I suppose we can have the snapshot generator do that, but it would still 
hard to differentiate between CVS versions then.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Kai Schrder
 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 (ignore all from user vercommt for instance) and
there must be a secure way to make commits for this special file without
having full dev karma.

Regards, Kai



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Derick Rethans
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? The php-cvs mailer
 should ignore the commits (ignore all from user vercommt for instance) and
 there must be a secure way to make commits for this special file without
 having full dev karma.

That can be done, but that means 12 commits a day for a single file. I 
dont think that's a good idea. 

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Kai Schrder
 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 are not mailed to php-cvs list?

Regards, Kai



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread James Aylett
   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. 

Is the ChangeLog updated religiously? If so, CVS builds could include a
datestamp acquired from that.

James
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/2003



This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] RfC: version names

2003-01-31 Thread Hartmut Holzgraefe
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

after a year this file would have a cvs release id of something like 1.4500

take a look at http://cvs.php.net/cvs.php/php4/NEWS to see why this might
be a not-so-good idea ...

--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED]   Tel.: +49-711-99091-77

Sie finden uns auf der CeBIT in Halle 6/H44   http://www.six.de/cebit2003/


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Sascha Schumann
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 usage per year. Where
 do you see the real problem if the commits are not mailed to php-cvs list?

Cluttering the history of an important file is an extremely
bad idea.

- Sascha

--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Derick Rethans
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 hours? 
 
  That can be done, but that means 12 commits a day for a single file. I 
  dont think that's a good idea. 
 
 Is the ChangeLog updated religiously? If so, CVS builds could include a
 datestamp acquired from that.

Only daily, but it seems like the correct way to do it to me.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Derick Rethans
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

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread James Aylett
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 ChangeLog updated religiously? If so, CVS builds could include a
  datestamp acquired from that.
 Only daily, but it seems like the correct way to do it to me.

That should be sufficiently fine-grained, at least for the moment. It
certainly
tightens the range of a codebase in a bug report from weeks or months down
to
a single day or so.

Cheers,
James
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/2003



This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Kai Schroder
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Sascha Schumann
  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 unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Derick Rethans
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 with snapshots, so he 
isn't smoking anything.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Sascha Schumann
 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
immediately.  But that is unlikely from my POV.

- Sascha

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Derick Rethans
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 conceivable that someone does not run buildconf
 immediately.  But that is unlikely from my POV.

It's not actually, as we were just trying to *solve* this problem and 
prevent getting test results with the wrong date/time. 

Derick, creator

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Sascha Schumann
 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 here?

- Sascha

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Derick Rethans
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 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 they're not made by a snapshot or our phport.sh thingy 
for automatic testing.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] RfC: version names

2003-01-31 Thread Sander Steffann
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 they're not made by a snapshot or our phport.sh thingy 
 for automatic testing.

Sounds a lot more reliable :)
Sander



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread James Aylett
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 working directory), but that is probably too
non-portable to be acceptable as part of the build system. (Okay, so you
could write a mini C util to do it that relied only on POSIX, but that's
still quite fiddly to get right.)

However that's still going to be misleading, because any report against it
has a reasonable chance of being bogus anyway, I'd have thought. It's
difficult to detect, though. Derick's suggestion of only allowing
submissions against at worst (in terms of moving targets) a snapshot build
is probably a fair compromise?

Cheers,
James
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 27/01/2003



This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Sascha Schumann
 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 discussed yet?

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

- Sascha

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] RfC: version names

2003-01-31 Thread Kai Schroder
 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 Source Date so we have it in addition to the version string and
the build date in phpinfo()?

Regards, Kai



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] RfC: version names

2003-01-31 Thread Xavier Spriet
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, 2003-01-31 at 08:29, 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 packet was used to
 build php. Is there any way to name the versions 4.3.0 (release), 4.3.1-dev
 (taken from cvs, additional timestamp would be nice), 4.3.1-snapMMDDHHii
 (taken from snaps.php.net) and 4.3.1-win32-snapMMDDHHii (Win32
 Snapshot)?
 
 This will make it more easy to follow the development and ignore allready
 fixed bugs. The goal is to find out which commit is the reason for the
 failure on which systems. If this works fine, we are able to add detailed
 comments to bugs.php.net and reopen automatic already closed bugs.
 
 Regards, Kai
-- 
Xavier Spriet [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP-DEV] RfC: version names

2003-01-31 Thread John Coggeshall


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: http://www.php.net/unsub.php