Everything

php

Automated selection of engine

php.internals

Sascha Schumann

23 years ago

Right now, CVS users have to know which engine they need for
a particular PHP version.  The reason for this?  The
php4/php5 CVS aliases have been removed, because they
conveyed a false impression -- php4 just wouldn't give you
PHP 4, if you did not also specify the correct branch.

So we are better off just relying on the branch info instead
of pretending that a CVS alias might do the trick.

Thus, how do we make

cvs co -r PHP_4 php-src
cvs co -r PHP_5 php-src

just work?

The simplest solution seems to be: Check out both engines all
the time.

This is simple on the CVS level, but there are two other
concerns:

- The UNIX build system uses hardcoded "Zend/" directory
names in a lot of places.  Might be solved by using mv(1)
in buildconf.

- The Win32 build system might rely on a specific dirname as
well.

So, we should get comfortable with the idea of having a Zend
_and_ a ZendEngine2 dir at the same time(*).

Thoughts?

(*) disk space/network bw is not an issue, when the
user-chosen branch of the unused engine is empty (e.g.
the PHP_5 branch in Zend would be empty).

- Sascha

Andi Gutmans

23 years ago

At 05:25 AM 6/24/2003 +0200, Sascha Schumann wrote:

>     So, we should get comfortable with the idea of having a Zend
>     _and_ a ZendEngine2 dir at the same time(*).
>
>     Thoughts?

I think in the long run it tends to be a bit ugly, but I don't see any
alternative right now, because merging the CVS histories doesn't seem to be
feasible to me. So I'm OK with it for now.
However, I am not convinced that having to explicitly checkout the PHP_5
branch is such a good idea. I thought the idea was to have HEAD be the
current development version and branch if off when necessary. I would
prefer this kind of approach.

Andi

Markus Fischer

23 years ago

On Tue, Jun 24, 2003 at 07:28:40AM +0200, Andi Gutmans wrote :

> However, I am not convinced that having to explicitly checkout the PHP_5
> branch is such a good idea. I thought the idea was to have HEAD be the
> current development version and branch if off when necessary. I would
> prefer this kind of approach.

I think the advantage of the requirement of the branch TAG is
that commit messages now always identify themselves where
they're comming from right within the subject.

Commit messages until the change from Sascha were always
named "[PHP-CVS] cvs: php4" though it was php5 really.

Now they all look like "[PHP-CVS] cvs: php-src(PHP_5)" which
imho is easier to identify were a single commit is comming
from.

This helps a lot if at a later stage you browser through
commit mails; you don't need to keep track which version HEAD
was at a given time; you simply read it in the subject.

my 2c,

- Markus

Sascha Schumann

23 years ago

> I think in the long run it tends to be a bit ugly, but I don't see any
> alternative right now, because merging the CVS histories doesn't seem to be
> feasible to me. So I'm OK with it for now.

With the empty branch concept, the unused engine directory
contains only a single anti-pruning file.

That would mean that the following branches need to emptied:

ZE1: HEAD
ZE2: PHP_4, PHP_4_3

> However, I am not convinced that having to explicitly checkout the PHP_5
> branch is such a good idea. I thought the idea was to have HEAD be the
> current development version and branch if off when necessary. I would
> prefer this kind of approach.

That looks preferably to me as well.  I've updated the
instructions.

http://schumann.cx/phpcvs.txt

- Sascha