Problems with php-src, PECL-linked extensions, and tagging

[email protected] (Gwynne Raskind) Tue, 30 Jun 2009 17:37:56 -0400
Newsgroups svn.migration
Message-ID <[email protected]>
In CVS, we symlink a number of extensions from PECL into php-src  
directly. That list is currently:

bz2, hash, oci8, pdo, pdo_dblib, pdo_firebird, spl, soap, sqlite,  
tidy, xmlreader, xmlwriter, filter, json, pdo_mysql, pdo_oci,  
pdo_odbc, pdo_pgsql, pdo_sqlite, simplexml, fileinfo

This symlinking is a logical fallacy and an unintended side-effect of  
the OS implementation of CVS: It allows us to pretend that one part of  
the repo exists AS part of the other.

You can't do that in SVN.

Externals in SVN don't function the same way as CVS symlinks. The  
linked external files are NOT treated as part of the linking module  
(in this case php-src). Especially, tags and branches (accomplished by  
svn cp) are NOT propogated across the externals. Which means when  
someone does "svn cp http://svn.php.net/php/php-src/trunk http://svn.php.net/php/php-src/branches/PHP_5_4 
", the externals will not be updated. None of those extensions listed  
above will get branched, and the svn:externals entry in php-src will  
not change to point away from the trunk of those extensions.

Commits in php-src don't propogate across externals either. So if you  
change both php-src/main/php_ini.c and ext/fileinfo/fileinfo.c and run  
svn commit from php-src/, the fileinfo change won't be committed.

Why is this functionality missing? Because it was never supposed to be  
there in the first place. CVS was in error by allowing us to work this  
way; it's extremely poor repository management practice. The SVN  
developers felt that separate projects should actually *be* separate  
projects, and that related projects should actually be related  
projects. We've been trying to hybrid the two and it no longer works.

What can we do about it? There are several solutions:

1) Do some evil twisted post-commit logic. It's possible to manually  
run the necessary recursive branch/tag commands and update the  
externals automatically. This is fragile and doesn't solve the  
"doesn't recurse into externals" problem.

2) Invert the svn:externals linkage, so that the canon files exist in  
php-src and the PECL packages pull from there as an external. This is  
conceptually unsound and still suffers the tag/branching propogation  
problem.

3) Do what the externals are trying to do already: Merge those PECL  
extensions into php-src once and for all. Hannes says those PECL  
packages never receive PECL releases, so there's no reason for them to  
exist in PECL at all. This removes the whole issue by making the  
extensions in question a part of php-src. No externals at all.

4) Live with the current limitations and trust people to do the  
necessary branching and tagging by hand, or perhaps write a script to  
automate the process of tagging and branching in php-src. This is  
error-prone, as people will forget to use the script, and the script  
can have bugs. The forgetting can be mitigated by adding code to pre- 
commit to disallow tagging or branching in php-src not done by the  
script.

My personal favorite is option 3, but since I recognize that this may  
be impractical, option 4 is a close second. I can write the necessary  
scripts easily enough, but this WILL delay the go time of SVN; the  
other options are faster (very slightly faster with option 1, but  
practically instantaneous for options 2 and 3).

Please, please, PLEASE discuss!

-- Gwynne