I agree, PHP5 should be used where it will actually make a real difference. Using 5 solely for the sake of using it is, in my opinion, unnecessarily burdensome. Derek Wright wrote:

On Jun 12, 2007, at 8:04 PM, Larry Garfield wrote:

...

The drush/drush_pm concept has my mouth watering. :-) Small request. Per Dries instigation on his blog, make the command line installer PHP 5 only. It's a non-critical piece of really cool functionality and makes a good "value-add" for PHP 5.

I'm all for the "Go PHP5!" effort...

However, I'm only in favor where there's a clear case that PHP5 would make the code any better. None of the code I have in mind for this functionality has anything to do with PHP4 vs. PHP5 changes. It's all trivial, plain-vanilla php code to glue the info from update_status.module together with some wisdom about CVS (with a little FAPI sprinkled in) to upgrade your site via CVS. Trying to force this to be a PHP5-only feature would actually be difficult, and totally contrived.

Therefore, I'm going to have to graciously decline your request in this case. But, I'll keep it in mind for the future.

Cheers, -Derek (dww)

-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com

sean - please read the links that derek provided and ask clarifying questions there is needed. i get the feeling you didn't read given the broad nature of your question. Sean Robertson wrote:

Can your describe in a little more detail exactly what this module does? I already use CVS to get all of my sites (I have a setup script that creates the vhost on our server, sets up the database and user, and downloads drupal from CVS).

Derek Wright wrote:

...

Hello world,

FYI for anyone who cares about deploying Drupal sites directly via CVS...

As per the discussions at:

http://drupal.org/node/124661 (about providing support to update_status for folks who deploy from CVS)

http://drupal.org/node/150316 (about moving all CVS-specific code out of update_status)

and my meta comments on Dries's article about git: http://buytaert.net/linus-torvalds-on-git

I decided to create a new contrib module called "CVS deploy": http://drupal.org/project/cvs_deploy

See the description on the project page for more info.

I'll make some release tags soon, probably once update_status 5.x-2.0 (at least a beta) is out. Meanwhile, HEAD is for 5.x core.

Cheers, -Derek (dww)

p.s. I hope to integrate this with drush_pm.module in the future to finally implement my dreams for a script to automatically update a site to the latest recommended official releases from all of your currently installed modules, directly via CVS. For the interested reader:

http://drupal.org/project/drush http://drupal.org/node/124661

p.p.s. This module is only targeted at power users/developers who deploy sites via CVS, which is why I'm spamming this list about it. ;)

On Jun 13, 2007, at 7:01 AM, Sean Robertson wrote:

I did, but it's not entirely clear exactly what functionality is in the module. The project page really needs to be updated with a feature list.

Fair enough. Actually, the project page *does* say what the module does, there's just not much yet, so it might be easy to miss: "At this point, the CVS deploy module is primarily useful if you use the Update status[1] module, in particular, the 5.x-2.* series (currently still in development, see the 5.x-2.x-dev[2] release). However, CVS deploy also alters the modules page at admin/build/ modules to put human-readable version strings in place, instead of the ugly $Name: DRUPAL-5--1-2 $ versions that are currently displayed when you deploy a Drupal site from CVS." However... cvs_deploy is also smart enough to figure out what tag/branch a given module was checked out with, even if the dreaded version = "$Name$" isn't in the .info file (it looks for a CVS/Tag file and figures it out from there). This means that we no longer should put this "version" line in the .info files in CVS at all. We only ever did that as a convenience for the power-users who deploy from CVS, and now we've got cvs_deploy to handle that problem for them, instead. (/me kicks self for not just writing cvs_deploy.module months ago). See http://drupal.org/node/151535 for confusion in the wild caused by this practice... Therefore be it resolved: Everyone should just remove the "version" definition in the .info files as committed to CVS. the packaging script will continue to add the right version string to the packaged tarballs. People who deploy directly from CVS should use cvs_deploy.module to get reasonable version strings on admin/build/modules, even if there's nothing in the .info files. Hope that clarifies what cvs_deploy.module is doing and why you want it. cheers, -derek p.s. the other code in there is basically doing the same sorts of tricks for the purpose of update_status.module knowing exactly what you currently have installed, even if it's from CVS, so it knows to tell you if you're out of date or not. [1] http://drupal.org/project/update_status [2] http://drupal.org/node/143593