[PHP-DOC] The PHP documentation activity report
Hello! This lists some of the activity found within the PHP documentation over at php.net. Of course numbers mean nothing alone, but they do show general activity around the PHP documentation. Dates of activity include: 2011-11-30 to 2011-12-07 Those who made SVN commits: --- (php.net svn modules: phpdoc, phd, web/doc-editor) frozenfire45 seros24 mch24 yannick24 shein21 laruence12 bfl11 northcat10 irker 9 takagi 6 khp 5 vrana 5 philip 3 rquadling 3 edwincartagenah 3 salathe 2 gooh 2 saltybeagle 1 jorgeeolayap 1 jesusruiz 1 dave 1 jvenegasperu 1 andresdzphp 1 hradtke 1 Those who closed documentation bugs: --- (bug categories: problem, translation, phd, editor) frozenfire24 yannick 2 gooh 1 seros 1 irker 1 Those who handled user notes: --- (actions: delete, reject, edit) danbrown26 tularis18 thiago12 joey 1 --- See also: - Edit the documentation online: https://edit.php.net/ - Documentation HOWTO: https://doc.php.net/dochowto/
Re: [PHP-DOC] Transition from Subversion to Git
On 11-12-07 01:35 PM, Hannes Magnusson wrote: On Wed, Dec 7, 2011 at 22:01, Justin Martin wrote: On 11-12-07 11:46 AM, Hannes Magnusson wrote: On Wed, Dec 7, 2011 at 18:09, Justin Martinwrote: On 11-12-07 02:58 AM, Hannes Magnusson wrote: On Wed, Dec 7, 2011 at 01:57, Justin Martin wrote: Hello everyone, There's been some informal discussion in #php.doc on EFnet about how the transition from Subversion to Git will be achieved, and what the resulting structure will look like. We can't use submodules. Submodules in git reference a specific commit, not "last commit" like it does in svn by default. If we use git submodules in means; Every time we update doc-base, you have to update the submodule in _all_ translations to the last commit and commit the change. -Hannes Hi Hannes, I was actually thinking of that issue, and thought that it would be a simple matter to use a client-side post-checkout hook to run "git submodules foreach git pull". That'd update each submodule. Not sure of the specifics in that regard, but I can't think of any other solution to that problem than submodules. Debugging client side post hooks is not something I want to even think about when debugging why some translation doesn't work. And, using this model, you would need to have 100 checkouts of doc-base if you have 100 translations locally. I would rather recommend that you simply have to do an explicit doc-base checkout and update, not bundling. Also, what worries me more is the way we determine if a file is up2date or not. git doesn't have these sort of keywords and the idea of bumping the files revision manually has been rejected several times (although not in this context, the idea was to eliminate the translators need to bump their version on english typo and ws fixes). -Hannes Hi Hannes, There's not much difference between the way that Subversion does svn:externals automatically, and scripting it with hooks in git. I mean, if Sure there is. One is something you explicitly need to configure - even before your first checkout, and the other "just works". you do have a better idea, I'm definitely all-ears, because I've been racking my brain for one. :P Well, my first thoughts are I would rather recommend that you simply have to do an explicit doc-base checkout and update, not bundling. that also solves the issue of having bucketloads of copies of the exact same repo. Not to mention no pre-configuration and trivial to debug. As for doing svn:keywords, I've already pretty-well solved that. https://github.com/TheFrozenFire/git-rcs-keywords That's a fork of a solution which uses clean and smudge filters, which I've modified from using Perl to using PHP. It's still in the works, but it's a reasonable solution to a complicated problem. This is just adding more and more prerequisites. Increasing the difficulty to get up and running and more frustration and issues debugging when it doesn't work for someone :( -Hannes Hi Hannes, Submodules are cloned automatically. With a simple hook, they can be updated on pull as well. That's almost exactly equivalent to the subversion way; the only difference is that it's something we configure explicitly. There's no increase in debugging that I can see. Everyone who is working on the documentation should necessarily have PHP installed. PHP (with pcre) is the only dependency that is added. It could probably even be set up to simply *not* update those keywords if PHP isn't available. No harm, no foul, the github version wouldn't know any different. Since the keywords are being replaced client-side, rather than server-side, and being reverted to their keyword form before the data is sent, there's nothing that would ever break. Those without PHP installed would still be able to edit the documentation. They simply wouldn't see the replaced keywords. That would only ever *possibly* be a problem for the translators, and it's a fairly mild one at that. Thanks, Justin Martin
Re: [PHP-DOC] Transition from Subversion to Git
On Wed, Dec 7, 2011 at 22:01, Justin Martin wrote: > On 11-12-07 11:46 AM, Hannes Magnusson wrote: >> >> On Wed, Dec 7, 2011 at 18:09, Justin Martin wrote: >>> >>> On 11-12-07 02:58 AM, Hannes Magnusson wrote: On Wed, Dec 7, 2011 at 01:57, Justin Martin wrote: > > > Hello everyone, > > There's been some informal discussion in #php.doc on EFnet about how > the > transition from Subversion to Git will be achieved, and what the > resulting > structure will look like. We can't use submodules. Submodules in git reference a specific commit, not "last commit" like it does in svn by default. If we use git submodules in means; Every time we update doc-base, you have to update the submodule in _all_ translations to the last commit and commit the change. -Hannes >>> >>> >>> >>> Hi Hannes, >>> >>> I was actually thinking of that issue, and thought that it would be a >>> simple >>> matter to use a client-side post-checkout hook to run "git submodules >>> foreach git pull". That'd update each submodule. >>> >>> Not sure of the specifics in that regard, but I can't think of any other >>> solution to that problem than submodules. >> >> >> Debugging client side post hooks is not something I want to even think >> about when debugging why some translation doesn't work. >> >> And, using this model, you would need to have 100 checkouts of >> doc-base if you have 100 translations locally. >> >> I would rather recommend that you simply have to do an explicit >> doc-base checkout and update, not bundling. >> >> >> Also, what worries me more is the way we determine if a file is >> up2date or not. git doesn't have these sort of keywords and the idea >> of bumping the files revision manually has been rejected several times >> (although not in this context, the idea was to eliminate the >> translators need to bump their version on english typo and ws fixes). >> >> -Hannes > > > Hi Hannes, > > There's not much difference between the way that Subversion does > svn:externals automatically, and scripting it with hooks in git. I mean, if Sure there is. One is something you explicitly need to configure - even before your first checkout, and the other "just works". > you do have a better idea, I'm definitely all-ears, because I've been > racking my brain for one. :P Well, my first thoughts are >> I would rather recommend that you simply have to do an explicit >> doc-base checkout and update, not bundling. that also solves the issue of having bucketloads of copies of the exact same repo. Not to mention no pre-configuration and trivial to debug. > As for doing svn:keywords, I've already pretty-well solved that. > https://github.com/TheFrozenFire/git-rcs-keywords > > That's a fork of a solution which uses clean and smudge filters, which I've > modified from using Perl to using PHP. It's still in the works, but it's a > reasonable solution to a complicated problem. This is just adding more and more prerequisites. Increasing the difficulty to get up and running and more frustration and issues debugging when it doesn't work for someone :( -Hannes
Re: [PHP-DOC] Transition from Subversion to Git
On 11-12-07 11:46 AM, Hannes Magnusson wrote: On Wed, Dec 7, 2011 at 18:09, Justin Martin wrote: On 11-12-07 02:58 AM, Hannes Magnusson wrote: On Wed, Dec 7, 2011 at 01:57, Justin Martinwrote: Hello everyone, There's been some informal discussion in #php.doc on EFnet about how the transition from Subversion to Git will be achieved, and what the resulting structure will look like. We can't use submodules. Submodules in git reference a specific commit, not "last commit" like it does in svn by default. If we use git submodules in means; Every time we update doc-base, you have to update the submodule in _all_ translations to the last commit and commit the change. -Hannes Hi Hannes, I was actually thinking of that issue, and thought that it would be a simple matter to use a client-side post-checkout hook to run "git submodules foreach git pull". That'd update each submodule. Not sure of the specifics in that regard, but I can't think of any other solution to that problem than submodules. Debugging client side post hooks is not something I want to even think about when debugging why some translation doesn't work. And, using this model, you would need to have 100 checkouts of doc-base if you have 100 translations locally. I would rather recommend that you simply have to do an explicit doc-base checkout and update, not bundling. Also, what worries me more is the way we determine if a file is up2date or not. git doesn't have these sort of keywords and the idea of bumping the files revision manually has been rejected several times (although not in this context, the idea was to eliminate the translators need to bump their version on english typo and ws fixes). -Hannes Hi Hannes, There's not much difference between the way that Subversion does svn:externals automatically, and scripting it with hooks in git. I mean, if you do have a better idea, I'm definitely all-ears, because I've been racking my brain for one. :P As for doing svn:keywords, I've already pretty-well solved that. https://github.com/TheFrozenFire/git-rcs-keywords That's a fork of a solution which uses clean and smudge filters, which I've modified from using Perl to using PHP. It's still in the works, but it's a reasonable solution to a complicated problem. Thanks, Justin Martin
Re: [PHP-DOC] Transition from Subversion to Git
On Wed, Dec 7, 2011 at 18:09, Justin Martin wrote: > On 11-12-07 02:58 AM, Hannes Magnusson wrote: >> >> On Wed, Dec 7, 2011 at 01:57, Justin Martin wrote: >>> >>> Hello everyone, >>> >>> There's been some informal discussion in #php.doc on EFnet about how the >>> transition from Subversion to Git will be achieved, and what the >>> resulting >>> structure will look like. >> >> >> We can't use submodules. >> Submodules in git reference a specific commit, not "last commit" like >> it does in svn by default. >> >> If we use git submodules in means; >> Every time we update doc-base, you have to update the submodule in >> _all_ translations to the last commit and commit the change. >> >> -Hannes > > > Hi Hannes, > > I was actually thinking of that issue, and thought that it would be a simple > matter to use a client-side post-checkout hook to run "git submodules > foreach git pull". That'd update each submodule. > > Not sure of the specifics in that regard, but I can't think of any other > solution to that problem than submodules. Debugging client side post hooks is not something I want to even think about when debugging why some translation doesn't work. And, using this model, you would need to have 100 checkouts of doc-base if you have 100 translations locally. I would rather recommend that you simply have to do an explicit doc-base checkout and update, not bundling. Also, what worries me more is the way we determine if a file is up2date or not. git doesn't have these sort of keywords and the idea of bumping the files revision manually has been rejected several times (although not in this context, the idea was to eliminate the translators need to bump their version on english typo and ws fixes). -Hannes
Re: [PHP-DOC] Transition from Subversion to Git
On 11-12-07 02:58 AM, Hannes Magnusson wrote: On Wed, Dec 7, 2011 at 01:57, Justin Martin wrote: Hello everyone, There's been some informal discussion in #php.doc on EFnet about how the transition from Subversion to Git will be achieved, and what the resulting structure will look like. We can't use submodules. Submodules in git reference a specific commit, not "last commit" like it does in svn by default. If we use git submodules in means; Every time we update doc-base, you have to update the submodule in _all_ translations to the last commit and commit the change. -Hannes Hi Hannes, I was actually thinking of that issue, and thought that it would be a simple matter to use a client-side post-checkout hook to run "git submodules foreach git pull". That'd update each submodule. Not sure of the specifics in that regard, but I can't think of any other solution to that problem than submodules. Thanks, Justin Martin
Re: [PHP-DOC] SVN Account Request: alejandrorodas
Philip, Can you please activate Alejandro´s SVN account? He said that many students at his university of computer science are taking advantage of our work and now its time for him to give back. These are the files he translated so far: /es/reference/pdo/prepared-statements.xml /es/reference/pdo/pdo/lastinsertedid.xml /es/reference/pdo/pdo/prepare.xml /es/reference/pdo/pdo/query.xml /es/reference/pdo/pdo/quote.xml Please find the files attached. Thank you! Yago On Tue, Dec 6, 2011 at 4:44 AM, Alejandro Rodas wrote: > I would like to have an SVN account to help with the Spanish translation > of the PHP Manual. > > -- Yago Ferrer http://docbook.org/ns/docbook"; xmlns:xlink="http://www.w3.org/1999/xlink";> Sentencias preparadas y procedimientos almacenados Muchas de las bases de datos más maduras soportan el concepto de sentencias preparadas. Pueden definirse como un tipo de plantillas compiladas para SQL que las aplicaciones desean ejecutar, que pueden ser personalizadas usando parámetros variables. Las sentencias preparadas ofrecen dos grandes beneficios: La consulta sólo necesita ser interpretada (o preparada) una vez, pero puede ser ejecutada en múltiples ocasiones con los mismos o diferentes parámetros. Cuando la consulta es preparada, la base de datos analizará, compilará y optimizará su plan para ejecutar la consulta. Para consultas complejas este proceso puede tomar suficiente tiempo como para que ralentice notablemente una aplicación si se necesita repetir la misma consulta muchas veces con los mismos parámetros. Usando una sentencia preparada la aplicación evita repetir el ciclo de análisis/compilación/optimización. Esto significa que las sentencias preparadas usan menos recursos y se ejecutan más rápidamente. Los parámetros para las sentencias preparadas no necesitan estar entrecomillados; el driver automáticamente se encarga de esto. Si una aplicación usa exclusivamente sentencias preparadas, el desarrollador puede estar seguro de que no ocurrirán inyecciones SQL (sin embargo, si otras partes de la consulta se construyen con datos de entrada sin escapar, las inyecciones SQL pueden ocurrir). Las sentencias preparadas son tan útiles que son la única característica que PDO emulará para drivers que no las soporten. Esto asegura que una aplicación será capaz de usar el mismo paradigma de acceso a datos independientemente de las capacidades de la base de datos. Múltiples inserts usando sentencias preparadas Este ejemplo realiza dos consulta de tipo INSERT sustituyendo name y value por los valores equivalentes. Múltiples inserts usando sentencias preparadas Este ejemplo realiza dos consultas de tipo INSERT sustituyendo name y value por el parámetro de sustitución?. Buscar datos usando sentencias preparadas Este ejemplo busca datos basándose en un valor clave proporcionado por un formulario. Los datos de usuario son automáticamente entrecomillados, con lo cual no hay riesgo de un ataque por inyección SQL. Si el driver de la base de datos lo soporta, una aplicación puede también enlazar parámetros de salida al igual que para entrada. Los parámetros de salida son típicamente usados para recuperar valores de procedimientos almacenados. Los parámetros de salida son ligeramente más complejos de usar que los de entrada, de manera que el desarrollador debe saber cuánto de grande puede ser un parámetro cuando se enlaza. Si el valor resulta ser más grande que el tamaño que se ha supuesto, se eleva un error. Llamar a un procedimiento almacenado con un parámetro de salida Los desarrolladores pueden también especificar parámetros que contendrán valores tanto de entrada como de salida; la sintaxis es similar a la de los parámetros de salida. En el siguiente ejemplo, la cadena 'hello' es pasada al procedimiento almacenado, y cuando éste finaliza, 'hello' es reemplazada con el valor de retorno del procedimiento. Llamar a un procedimiento almacenado con un parámetro de entrada/salida Uso inválido de un parámetro de sustitución http://docbook.org/ns/docbook";> PDO::lastInsertId Devuelve el ID de la última fila o secuencia insertada &reftitle.description; stringPDO::lastInsertId stringname&null; Devuelve el ID de la última fila insertada, o el último valor de una secuencia de objetos, dependiendo del driver subyacente. Por ejemplo, PDO_PGSQL requiere especificar el nombre de la secuencia de objetos para el parámetro name. Este método puede no devolver resultados significativos o consistentes para diferentes drivers PDO, debido a que la base de datos subyacente puede no soportar el concepto de campos au
Re: [PHP-DOC] Transition from Subversion to Git
On Wed, Dec 7, 2011 at 01:57, Justin Martin wrote: > Hello everyone, > > There's been some informal discussion in #php.doc on EFnet about how the > transition from Subversion to Git will be achieved, and what the resulting > structure will look like. We can't use submodules. Submodules in git reference a specific commit, not "last commit" like it does in svn by default. If we use git submodules in means; Every time we update doc-base, you have to update the submodule in _all_ translations to the last commit and commit the change. -Hannes
