RE: [PEAR-DEV] [RFC] CVS directory structure

Hi, Ok I do things as follows with MDB and I think its a great method (for me) to develop. Please note that MDB (just as DB) is special in that it is a package that requires subdirs, but since it installs itself one level lower than most packages (that is in the root dir) and since it is its own top level category everything pretty much works for me just like Toby is suggesting. For the other package I work on (LiveUser) this is not the case which I find quite annoying. 1) I have 1 checkout of PEAR. 2) modify my files in that dir. 3) I can immediately see which files I have changed. 4) I can always compare my changed files with all prior versions. 5) I can immediately commit the same files which I run my tests on. 6) If other people change the same files I can either not update, update specific files or let CVS help me with the merge. 7) I can tell people to run the tests, examples straight out of CVS (In the tests I simply add the necessary include path via ini_set) .. they don't need to do anything aside from checking out and maybe editing the conf files To me developing in CVS is the only way. On LiveUser things are different 1) There I have to copy around files to make a diff with a previous version 2) There I don't know which of the tons of files I have already messed with 3) There users will not be able to assist in debugging easily unless I make a package for them (which adds work for me) and it also prevents users from casually keeping track of how things go in the development 4) If I want to merge changes that other people did I have to copy things back and forth or I have to manually do what CVS is supposed to do -> handle merging Anyways on unix I could of course symlink, but I don't understand why I should jump through hoops? I don't see a single draw back to what Toby suggested aside from the fact that its not the current standard and that you end up with a few extra dirs which are empty (so with tab completion on the shell and mouse clicking you can quickly make your way to the guts). Anyways I don't see a reason to beat people towards this with a stick however. So I am very much in favour of making this optional. Regards, Lukas