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