RE: [PEAR-DEV] requiring cvs (was: a case for subpackages)

> From: Greg Beaver [mailto:greg@chiaraquartet.net] > Sent: Monday, August 25, 2003 8:14 AM > Marshall Roch wrote: > > > Greg Beaver wrote: > > I just installed PEAR on my machine so that I can test my XML_RPC > > changes more easily. I noticed that the pear command line has a > > "cvsdiff" option. Wouldn't it be even more efficient to have > > something like "pear patch <package>" to patch the code with the > > latest [stable] release from CVS? This, of course, would require that > > using PEAR's CVS becomes mandatory, which I don't see as such a bad > > thing. > I'm very against requiring PEAR CVS. phpDocumentor, for example, had a > long history of using a different CVS repository before becoming a PEAR > project. We have developers who have absolutely nothing to do with PEAR > who help to develop it, and there is no good reason to throw everything > off by requiring them all to get PHP cvs access and change all of their > local repositories, not to mention the complete loss of any commit > history. I also tend to agree here. I don't know if it's a god idea to change that rule at this stage. However I think we should require that the CVS is public so that we can make incremental backups of the CVS (or even sync it over to pear CVS). This is especially important if a package that is not in CVS ever becomes orphaned. Just a thought. > Patches contains absolutely no stability information, and they also lose > all the benefits of the pear installer (replacements, install-as, > OS-specific install, different baseinstalldir). For these reasons, it > would be less efficient for complex packages/applications (the only ones > that would use the subpackage feature are complex, so there you go :). Just a side note: Well having an easy way to distribute patches and easily (de)install them on the userside might be a good thing for QA. Regards, Lukas