RE: [PHP-DEV] RfC: version names

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

RE: [PHP-DEV] RfC: version names

>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 To unsubscribe, visit: http://www.php.net/un

Re: [PHP-DEV] RfC: version names

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, 200

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

> 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 a

RE: [PHP-DEV] RfC: version names

> 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 bee

RE: [PHP-DEV] RfC: version names

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 i

Re: [PHP-DEV] RfC: version names

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

RE: [PHP-DEV] RfC: version names

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

RE: [PHP-DEV] RfC: version names

> 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 her

RE: [PHP-DEV] RfC: version names

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 >

RE: [PHP-DEV] RfC: version names

> "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

RE: [PHP-DEV] RfC: version names

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 n

RE: [PHP-DEV] RfC: version names

> > 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 To u

RE: [PHP-DEV] RfC: version names

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

RE: [PHP-DEV] RfC: version names

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): > > I

RE: [PHP-DEV] RfC: version names

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 --

RE: [PHP-DEV] RfC: version names

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

RE: [PHP-DEV] RfC: version names

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 d

Re: [PHP-DEV] RfC: version names

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

RE: [PHP-DEV] RfC: version names

> > > 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

RE: [PHP-DEV] RfC: version names

> 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 comm

RE: [PHP-DEV] RfC: version names

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 hou

RE: [PHP-DEV] RfC: version names

> 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 (ig

Re: [PHP-DEV] RfC: version names

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

[PHP-DEV] RfC: version names

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 ve