Re: [RFC] CVS directory structure

I'm -1 on this. CVS is a tool for source control. Doing development directly on your CVS dir is a bad idea. Besides that, the new structure would not be the same as the installed one anyway. tests and data are in the first level in the installed pear dir structure while inside each package's dir in the CVS one. Xavier Tobias Schlitt <tobias@schlitt.info> escribió > Hi all! > > So, after all those discussions during my test, I'd now like to have a > real proposal for that, because it seems quite usefull to me. Please > leave all your flames at home for another post (or hopefully for another > list). Thanks a lot! > > HTML Version: http://schlitt.info/RFCs/cvs_dir_structure.htm > > -------- > Proposal > -------- > > Topic > ----- > > This proposal regards the directory structure of the pear module inside > the official PHP CVS (http://cvs.php.net). > > Problem > ------- > > The directory structure of the user's pear directory is different from > the one of th CVS module. This results in a problem in respect to > include mechanisms of PEAR. This issue has been solved through different > uncomfortable filesystem operations. > > Current structure of the PEAR user diretory: > > pear/ > Image/ > Text/ > Line.php > Text.php > > Current CVS structure: > > pear/ > Image_Text/ > Text/ > Line.php > Text.php > > Example: > > A normal require statement inside a PEAR package looks like this: > > require_once 'Image/Text/Line.php'; > // Include subpackge > or > require_once 'Image/Tools.php' > // Include dependency package > > Which would both result in an error if you just add it to the > include_path. It is not possible to solve this without having to do > several filesystem operations (e.g. copying of files into a new > directory structure, create new directory with "ln -s" links (*nix > only!),...). > > Issues: > - Uncomfortable for developement (high effort before and after each > developement cycle). > => reduces patch creation by foreigners > => reduces tests by foreigners > => scare potential developement > - Difficult to install (figure out, what to do; use of suboptimal > solutions). > => reduces patch creation by foreigners > => reduces tests by foreigners > => scare potential developement > > Solution > -------- > > To solve this issue, one of the following solutions should be > (optional?) used for a packages CVS directory. > > 1. > > Change the PEAR CVS directory structure to reflect the PEAR user > directory structure completly. Simply use ini_set('include_path', > '/your/cvs/pear'); or any other mechanism to require PEAR directories. > > Cons: > - Extreme change on PEAR CVS structure. > - No per-package influence on include basis. > > Pros: > - Very easy developement. > - Very comfortable developement. > > 2. > > Change the PEAR CVS directory structur to reflect parts of the PEAR user > directory structure. Insert a directory level into every package > directory which is named after the category and store all package needed > files below this. > > Example: > pear/ > Image_Text/ > Image/ > Text/ > Line.php > Text.php > > Simply use ini_set('include_path', "/your/cvs/pear/Image_Text:" . > ini_get('include_path')); to require one or more packages from their CVS > directory (for multiple packages you have to add multiple strings before > the old include_path). > > Cons: > - x > Pros: > - Very easy developement. > - Very comfortable developement. > - No per-package influence on include basis. http://www.xavier-noguer.com/