Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » CVS Administriva (important) »

CVS Administriva (important)

php.internals

James Cox

23 years ago
Guys, CVS has been moved around somewhat. The first stage is completed, hence this message. PHP5 now exists as it's own module. This was long overdue. Updating it should be fine -- just do a cvs update -dP. This may give you a bunch of warnings, but once done, everything should be updated. If you have problems, then a new checkout will resolve them. cvs -d :pserver:<user>@cvs.php.net:/repository checkout php5 PECL now has been promoted to it's own repository. Right now people with php tree access can also write to PECL, but if this begins to be a problem, then we can create a separate avail entry. The next stage to happen is that I will bring php4 HEAD into sync with the 4.x development branch, so expect a big patch. -- james
-- James Cox :: james@imajes.info :: http://imajes.info/ Was I helpful? http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/ Alien: I bring you love! Larry: It's bringing love, don't let it get away! Karl: Break its legs! Lisa: No! Wait! [Shines torch on alien to reveal Mr. Burns] Willy: Argh! It's a monster! Kill it, kill it! Smithers: No, stop! It's not a monster, it's Mr Burns! Willy: Ahhh, it's Mr Burns. Kill it, kill it!!

Derick Rethans

23 years ago
On Mon, 23 Jun 2003, James Cox wrote:
> The next stage to happen is that I will bring php4 HEAD into sync with > the 4.x development branch, so expect a big patch.
ARGH! Didn't I ask you NOT to do this... you just created a lot of trouble for people working with a php5 checkout (co php5)... it now updated to the PHP_4_3 branch. Result: [root@saturnus php-5.0.0dev]# cvs update cvs server: Updating . P .gdbinit P CODING_STANDARDS U ChangeLog P EXTENSIONS P LICENSE P Makefile.global P NEWS P README.EXT_SKEL P README.PARAMETER_PARSING_API P README.STREAMS P README.SUBMITTING_PATCH P README.TESTING P README.Zeus P TODO P acinclude.m4 P buildconf ... [root@saturnus php-5.0.0dev]# cat main/php_version.h /* automatically generated by configure */ /* edit configure.in to change version number */ #define PHP_MAJOR_VERSION 4 #define PHP_MINOR_VERSION 3 #define PHP_RELEASE_VERSION 3 #define PHP_EXTRA_VERSION "RC2-dev" #define PHP_VERSION "4.3.3RC2-dev" Great, thanks for this nice mess, we now ended up with useles PHP 4.3 checkouts with PHP 5 development stuff in it. Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Per Lundberg

23 years ago
On Mon, 2003-06-23 at 11:04, Derick Rethans wrote:
> Great, thanks for this nice mess, we now ended up with useles PHP 4.3 > checkouts with PHP 5 development stuff in it.
Yeah, what's the big deal about that? Just get the php5 module from CVS... Breakage is neccessary sometimes. James: thanks for fixing this in the proper way.
-- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.nobolt.com

Derick Rethans

23 years ago
On Mon, 23 Jun 2003, Per Lundberg wrote:
> On Mon, 2003-06-23 at 11:04, Derick Rethans wrote: > > Great, thanks for this nice mess, we now ended up with useles PHP 4.3 > > checkouts with PHP 5 development stuff in it. > > Yeah, what's the big deal about that? Just get the php5 module from > CVS...
Sure, and delete my work from my current checkout right away then? You obviously have no clue.
> > Breakage is neccessary sometimes. James: thanks for fixing this in the > proper way.
What business is that of yours? You're not contributing to the PHP source at all, only annoying us with useles comments. regards, Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

Per Lundberg

23 years ago
On Mon, 2003-06-23 at 11:35, Derick Rethans wrote:
> Sure, and delete my work from my current checkout right away then? You > obviously have no clue.
I didn't say that, Derick. You can still get a CVS diff that you can apply to the php5 tree and keep working.
> > Breakage is neccessary sometimes. James: thanks for fixing this in the > > proper way. > What business is that of yours?
Well, it is my business as a php5 user and tester. This list gets email regularly from people who are checking out php4 and fail to compile it. Do you not agree that there is a reason for this, and that reason is that the CVS was organized in a bad, hackish way?
-- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.nobolt.com

Wez Furlong

23 years ago
The point is that there are now a number of core developers who updated their existing php5 checkouts and now have a load of crap from 4.3 merged into their php5 development. Yes, its a nice idea to make php4 HEAD work for php4 again, but after a grace period to allow people to migrate to the "real" php5 repository. All we have now is a complete mess and another hold-up for php5 development. This is the second or third time my php5 tree has been fucked up by people acting without thinking it through; our time is limited and now we have to mess around making diffs for something that worked fine yesterday? I think you need to reconsider your idea of what "fixed" really means. Now, unless you have something positive to contribute (are you going to remove the crap from our local php5 development trees?), please kindly stop trolling and keep your opinion to yourself. --Wez. On Mon, 23 Jun 2003, Per Lundberg wrote:

James Cox

23 years ago
> > The point is that there are now a number of core developers > who updated their existing php5 checkouts and now have a load > of crap from 4.3 merged into their php5 development. >
For what it's worth, the last 5 or so warning emails I have dropped onto the list making it very clear what the path to upgrade would be should have made it very clear as to what was going to happen. That said, I did not take into account developers who would, for their own reasons, update cvs as the first thing they'd do before reading mail. (I always read mail first, so perhaps you can excuse me that assumption). At any rate, it should still be possible to do a cvs diff into a patch for new trees, and with a bit of magic you could diff against $current_revision - 1. But, before you lump scorn and disdain all over me, can I just point out that, even though I made the mistake of not giving you guys some time to migrate, this "hackish, not thinking things through" method of doing things got us into this problem in the first place. However much it tries to be able to do it, cvs is just not capable of the revision management that is needed unless you truly are a RCS expert, hence the need for an entirely separate module. By pushing php4 HEAD back to development (and to be honest, I'm not sure if it's ever going to get back to being a usable codebase, it's so broken with various cvs deletes etc that need to get readded) it forces people to stop using it to check in php5 stuff. Of course, I could have alternatively denied access to that tree for a couple of days whilst you got reaquainted -- but then again, that would have slowed 4.3.3. So apologies for the slight inconvenience... But lets be honest, if it will take you longer than 1/2 hour to get your trees in order again, then you aren't using revision control properly. -- james

Sascha Schumann

23 years ago
Can someone explain why James just made it impossible to properly work with source code which resides in PHP 4 and 5? - diffing is impossible - merging is impossible - history of new commits becomes fragmented James, why did not you discuss this first? All opensource BSDs have been using _one_ source module since their inception. In the case of FreeBSD, that dates back to 1993, so this is clearly a proven model. What do the active developers on this list think? - Sascha

Edin Kadribasic

23 years ago
On Mon, 23 Jun 2003, Sascha Schumann wrote: [snip]
> James, why did not you discuss this first? All opensource BSDs > have been using _one_ source module since their inception. > In the case of FreeBSD, that dates back to 1993, so this is > clearly a proven model. > > What do the active developers on this list think?
I don't see a reason for separating repositories either. A mistake made by a few novice PHP CVS users doesn't warrant this change IMO. Edin

Allowee

23 years ago
On Monday 23 June 2003 17:43, Sascha Schumann wrote:
> Can someone explain why James just made it impossible to > properly work with source code which resides in PHP 4 and 5? > > - diffing is impossible > - merging is impossible > - history of new commits becomes fragmented > > James, why did not you discuss this first? All opensource BSDs > have been using _one_ source module since their inception. > In the case of FreeBSD, that dates back to 1993, so this is > clearly a proven model. > > What do the active developers on this list think? > > - Sascha
Just a question here.... can't somebody just put the yesterday backup of the repository in there? check the list to patch the files which where not backed up. all comments are welcome, just don't tell me that there is NO backup. .: Allowee

Derick Rethans

23 years ago
On Mon, 23 Jun 2003, Allowee wrote:
> can't somebody just put the yesterday backup of the repository in there? > check the list to patch the files which where not backed up. > > all comments are welcome, just don't tell me that there is NO backup.
I made a backup, cause I was expecting this. This doesn't mean that all conflicts that occured on developers' dev boxes due to the big mess^H^Hrge are totally broken now. Derick
-- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

James Cox

23 years ago
> Can someone explain why James just made it impossible to > properly work with source code which resides in PHP 4 and 5? > > - diffing is impossible > - merging is impossible > - history of new commits becomes fragmented > > James, why did not you discuss this first? All opensource BSDs > have been using _one_ source module since their inception. > In the case of FreeBSD, that dates back to 1993, so this is > clearly a proven model. >
The proposal was floated on the list a few weeks back, from which I referred to this change frequently. The problem is that you cannot sustain such radical changes in source this way. The differences between php3 and php4 are similar to the differences between php4 and php5, with many radical changes to the source code being made in php5. This change allows for proper management of code as we move forward. The tree became fubar the first time someone decided that, in their haste, to start turning php4 HEAD into php5 development. There is one fix for all of this, the most appropriate fix, which is to properly revert a file to revisions previous to the first php5 development, and then bring HEAD into sync with the branch [1]. BSD may be able to make use of one tree, however many open source projects create new modules (eg, apache) and others further have even more screwed up revision control (linux kernel). Just to highlight, once again, the changes that needed to be made to php5 to allow for PECLed extensions etc are only made possible by manually massaging the tree into such a state that permutations that once were not possible are now possible again. -- james

James Cox

23 years ago
> > There is one fix for all of this, the most appropriate fix, > which is to properly revert a file to revisions previous to > the first php5 development, and then bring HEAD into sync > with the branch [1]. >
The reference here was http://elib.cs.berkeley.edu/admin/cvs/cvsrevert.html ... Seems to have gotten lost from the email. -- james

Sascha Schumann

23 years ago
James, in the past, there was very little interest in a PHP 4 HEAD branch, if you care to recall. Because your rashness has rendered diff and merge unusable between PHP 4/5, we can only expect to see even less interest. Lowering the bar should be the answer to faiding interest, not raising..
> referred to this change frequently. The problem is that you cannot > sustain such radical changes in source this way. The differences between > php3 and php4 are similar to the differences between php4 and php5, with > many radical changes to the source code being made in php5.
You are confusing two issues here which leads you to a wrong conclusion. 1.) Moving files inside the repository PHP 3 contained all extension code in one directory. These files were moved to separate extension directories for PHP 4. In such a case, it is impossible to properly maintain a direct reference between the involved files. For PHP 5, the extension directories are moved into their own modules. These are 'projected' back into the php5 module by using CVS tricks. The same tricks can be used for a php4 or php-src module. As such, there is no visible difference from the outside at all, and hence no restructuring from a CVS user perspective. 2.) Source code changes I'd estimate that >90% of the non-engine code remains the same. Thus, I fail to see any of the perceived radical changes. An evolutionary step is the perfect candidate for a new branch; it does not warrant a repository split. - Sascha

Stanislav Malyshev

23 years ago
SS>> clearly a proven model. SS>> SS>> What do the active developers on this list think? I think there's no problem in having PHP4 and PHP5 in single repository as branches. However, I can live with different modules too. So far I have seen almost no arguments from either side besides the ultimate "it is better this way" one. Sascha just now has provided one for one-module model - that it allows diffing and merging and history tracking - though if php4 and php5 would part their ways, which is already happening, I'm not sure it matters, since you would never directly merge php4 code into php5 and vice versa once they have become separated enough.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.109

Wez Furlong

23 years ago
Err, no. *Hacking the repository is not using revision control properly*. The problem is that I now have conflicts in my changes because CVS was doing its job and merging changes into my local code. In addition, some of my changes have been clevery merged with 4.3 specific changes. So, I have to go and audit my code by hand and check which of the changes I made, and which are changes made by CVS while trying to merge stuff from the other branch. CVS diff will not help here. This is fubar, and it will probably be easier to make a clean start and rewrite all that code from scratch. --Wez. On Mon, 23 Jun 2003, James Cox wrote:

James Cox

23 years ago
> > The problem is that I now have conflicts in my changes > because CVS was doing its job and merging changes into my > local code. In addition, some of my changes have been > clevery merged with 4.3 specific changes. So, I have to go > and audit my code by hand and check which of the changes I > made, and which are changes made by CVS while trying to merge > stuff from the other branch. > > CVS diff will not help here. >
There is a cumulative patch available here: http://cvs.php.net/~imajes/big.patch.gz which incorporates all the changes from PHP_4_3 to HEAD, which I merged. Simply by reversing the patch and applying it backwards to your code should be sufficient to remove the changes occurred when updating from CVS. -- james

Hartmut Holzgraefe

23 years ago
James Cox wrote:
> There is a cumulative patch available here: > http://cvs.php.net/~imajes/big.patch.gz which incorporates all the > changes from PHP_4_3 to HEAD, which I merged. Simply by reversing the > patch and applying it backwards to your code should be sufficient to > remove the changes occurred when updating from CVS.
i'm glad that i am not in the situation to test this out (today i really read *all* my mail before doing daily cvs updates ;), but can you please explain how this is supposed to be working on CVS conflict entries?
-- Hartmut Holzgraefe <hartmut@php.net>

Andi Gutmans

23 years ago
At 05:43 PM 6/23/2003 +0200, Sascha Schumann wrote:
> Can someone explain why James just made it impossible to > properly work with source code which resides in PHP 4 and 5? > > - diffing is impossible > - merging is impossible > - history of new commits becomes fragmented > > James, why did not you discuss this first? All opensource BSDs > have been using _one_ source module since their inception. > In the case of FreeBSD, that dates back to 1993, so this is > clearly a proven model. > > What do the active developers on this list think?
I am not quite sure how/what broke. However, no matter if what James did was the right or wrong thing to do, I think it should have been discussed first (in detail). Andi

Rasmus Lerdorf

23 years ago
On Mon, 23 Jun 2003, Andi Gutmans wrote:
> At 05:43 PM 6/23/2003 +0200, Sascha Schumann wrote: > > Can someone explain why James just made it impossible to > > properly work with source code which resides in PHP 4 and 5? > > > > - diffing is impossible > > - merging is impossible > > - history of new commits becomes fragmented > > > > James, why did not you discuss this first? All opensource BSDs > > have been using _one_ source module since their inception. > > In the case of FreeBSD, that dates back to 1993, so this is > > clearly a proven model. > > > > What do the active developers on this list think? > > I am not quite sure how/what broke. However, no matter if what James did > was the right or wrong thing to do, I think it should have been discussed > first (in detail).
A bunch of things are broken. Files are missing in php4 head and the wrong versions of files are also in there. I think we need to roll this change back as soon as possible and take another shot at this in a much more organized manner. -Rasmus

Jon Parise

23 years ago
On Mon, Jun 23, 2003 at 10:32:56AM -0700, Rasmus Lerdorf wrote:
> A bunch of things are broken. Files are missing in php4 head and the > wrong versions of files are also in there. I think we need to roll this > change back as soon as possible and take another shot at this in a much > more organized manner.
After giving the current state of things some thought, I think I prefer Sascha's implied proposal of developing PHP in a single CVS module named 'php'. The 'php4' and 'php5' aliases would point to their respective tags ('php4' => 'PHP_4', 'php5' => 'HEAD'). When PHP5 ships as a stable product, a 'PHP_5' branch is created, stable development happens there, and 'php6' is created, which points to HEAD.
-- Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/)

Sascha Schumann

23 years ago
> A bunch of things are broken. Files are missing in php4 head and the > wrong versions of files are also in there. I think we need to roll this > change back as soon as possible and take another shot at this in a much > more organized manner.
Here is a plan. - rename /repository/php5 to /repository/php-src - copy PHP_4_3 tags to PHP_4 branch (i.e. reset the PHP 4 head branch to the current 4.3 code) - workaround Zend/ZendEngine2 issue (they should be in the same module) by using CVS aliases - rm -rf /repository/php4 - reapply the 3 or 4 patches to the PHP_4_3 branch And first and foremost: - Make branch names crystal clear to developers - Sascha

Uwe Schindler

23 years ago
Sounds good. If you have time do it in that way. +1 At 20:04 23.06.2003 +0200, Sascha Schumann wrote:

Andi Gutmans

23 years ago
At 08:04 PM 6/23/2003 +0200, Sascha Schumann wrote:
> > A bunch of things are broken. Files are missing in php4 head and the > > wrong versions of files are also in there. I think we need to roll this > > change back as soon as possible and take another shot at this in a much > > more organized manner. > > Here is a plan. > > - rename /repository/php5 to /repository/php-src > - copy PHP_4_3 tags to PHP_4 branch (i.e. reset the PHP 4 > head branch to the current 4.3 code) > - workaround Zend/ZendEngine2 issue (they should be in the > same module) by using CVS aliases > - rm -rf /repository/php4 > - reapply the 3 or 4 patches to the PHP_4_3 branch > > And first and foremost: > > - Make branch names crystal clear to developers
Sounds good to me. Andi

James Cox

23 years ago
> > I am not quite sure how/what broke. However, no matter if > what James did was the right or wrong thing to do, I think it should
have
> been discussed first (in detail). >
The opportunity was made available, many times. -- james

Rasmus Lerdorf

23 years ago
On Mon, 23 Jun 2003, James Cox wrote:
> > I am not quite sure how/what broke. However, no matter if > > what James did was the right or wrong thing to do, I think it should > have > > been discussed first (in detail). > > > > The opportunity was made available, many times.
Lack of feedback does not mean you can go ahead and do whatever you want and mess up the repository. Lack of feedback tends to mean nobody feels strongly enough about it to make any changes, so you leave it alone. -Rasmus

Andi Gutmans

23 years ago
At 10:32 AM 6/23/2003 -0700, Rasmus Lerdorf wrote:
>A bunch of things are broken. Files are missing in php4 head and the >wrong versions of files are also in there. I think we need to roll this >change back as soon as possible and take another shot at this in a much >more organized manner.
Maybe it's really best to restore a backup and not fix it manually and then decide how to approach this. Andi

James Cox

23 years ago
> > At 10:32 AM 6/23/2003 -0700, Rasmus Lerdorf wrote: > >A bunch of things are broken. Files are missing in php4 > head and the > >wrong versions of files are also in there. I think we need to roll > >this change back as soon as possible and take another shot > at this in a > >much more organized manner. > > Maybe it's really best to restore a backup and not fix it > manually and then decide how to approach this.
At any rate, the current php4 tree should be synced with a backup from before the change. Let me clear up what the problems are, and lets discuss a method of fixing them. Right now, PHP5 should continue in the php5 module. Sascha is slightly wrong in his assesment that PHP5 development can continue as it was (HEAD of php4). A bunch of out dated folders needed to be moved permanently out the way, and the only way to do that safely is to remove it properly from cvs. (I hasten to add that svn does this properly already). The problem we have instead is that php4 can now only continue in the PHP_4_3 branch. This is because HEAD is perverted with PHP5 only code, and code removals (thanks guys. You know who you are.) which have caused incompatibilities. The solution which I see as being the most appropriate: cvs admin -o<revision that is good +1> <file> For each file in the repository. This includes deleted files where the deletion and any edits need to be removed. Then the code from the branch needs to be added to HEAD. At that point, php4 HEAD should compile as what it is labeled as being. -- james

Uwe Schindler

23 years ago
After all discussions what should we do with our 2 checkouts (PHP5-HEAD and PHP 4.3.3RC2). I have checked out php5 and used HEAD. -> Looks good On my harddisk is also a checkout of php4 with tag PHP4_3 (this seems to be the same with the STABLE snapshot) Today I checked also out php4 HEAD and have seen that this seems to look similar to PHP4_3 only the fileversions were updated by imajes. So what I want to know: How should I commit changes to PHP 4.3.3RC2 (using PHP4_3 as TAG or with the new php4-HEAD checkout)? If the last is correct (HEAD) somebody should set the TAG HEAD==PHP4_3 - this would make life easier for all... Some clearance would be nice! Uwe At 14:21 23.06.2003 +0100, James Cox wrote:
> > > > The point is that there are now a number of core developers > > who updated their existing php5 checkouts and now have a load > > of crap from 4.3 merged into their php5 development. > > > >For what it's worth, the last 5 or so warning emails I have dropped onto >the list making it very clear what the path to upgrade would be should >have made it very clear as to what was going to happen. > >That said, I did not take into account developers who would, for their >own reasons, update cvs as the first thing they'd do before reading >mail. (I always read mail first, so perhaps you can excuse me that >assumption). At any rate, it should still be possible to do a cvs diff >into a patch for new trees, and with a bit of magic you could diff >against $current_revision - 1. > >But, before you lump scorn and disdain all over me, can I just point out >that, even though I made the mistake of not giving you guys some time to >migrate, this "hackish, not thinking things through" method of doing >things got us into this problem in the first place. However much it >tries to be able to do it, cvs is just not capable of the revision >management that is needed unless you truly are a RCS expert, hence the >need for an entirely separate module. > >By pushing php4 HEAD back to development (and to be honest, I'm not sure >if it's ever going to get back to being a usable codebase, it's so >broken with various cvs deletes etc that need to get readded) it forces >people to stop using it to check in php5 stuff. Of course, I could have >alternatively denied access to that tree for a couple of days whilst you >got reaquainted -- but then again, that would have slowed 4.3.3. > >So apologies for the slight inconvenience... But lets be honest, if it >will take you longer than 1/2 hour to get your trees in order again, >then you aren't using revision control properly. > > -- james > > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php
----- Uwe Schindler Addr 1: Bamberger Str. 24a, D-96049 Bamberg Addr 2: Drausnickstr. 153, D-91052 Erlangen http://www.thetaphi.de - http:///www.schindlers-software.de eMails: uwe@thetaphi.de (private); info@schindlers-software.de (company) Tel./Fax: +49 700 PCLATEIN (+49 700 72528346) Schindlers Software - Home of Schindlers PC-LATEIN 3.10 DIE Software zum Lateinlernen!