My projects use usually many libraries which our developlement team has in CVS.
How can I integrate more (than one) CVS modules in the same project?

I would like to have the possibility to set the cvs module name on a per directory basis. If I don't set a name for the directory X it has to inherit the cvs module name of the parent.

What do you think about?

I think that the solution to copy the files from other projects where I checkout the files for each modulo isn't very nice

I think that if there were reasons to separate the things and hold them in different CVS modules and/or repositories, there might be reasons to separate them in the phped workspace too. I mean, that those directories might be done as different projects in the same workspace. I think case I see no problems with handling different CVS modules/repositores. Does it make sense?

If I handle the libraries in different projects how can I include them in the main project ?

eg. the libraries in CVS are a.php, b.php, c.php all in different modules

from my main project I've to include them
require "a.php"
require "b.php"
require "c.php"

it seems impossible having them in different projects, not?

as far as I see, it is not only possible but desirable .
What does make you feel it's impossible?

how is it possible without copying (at hand without CVS) each script from their original project to each project which use them?

I would like to import the library in each project through CVS and as far as each library is in its own module I don't see any way to do this if not having each library in a different directory and assign to this directory a different cvs module

If you've other solutions they're wellcome!

Each module stored in CVS is probably checked out into its own directory. If so, it's just fine to have these directories as roots for the projects.
Then enable CVS for each project and update properties on the CVS tab.
That's all the tricks actually
You'll see files (scripts) in their own project without any re-arrangements.

Then you'll probably want to make active the main project and include all other projects root directories to its Code Insight list.

using your suggestion how can I make a "require a.php" from a project that has another document_root, a different http space and possibly a chrooted environment?

if the main project is
/projects/main/

the libraries are:
/projects/a/
/projects/b/
/projects/c/

from /projects/main/index.php I'm NOT able to do a require of a script OUT OF the httpdocs of the project (in this case /projects/main/)

You say:
<quote>"it's just fine to have these directories as roots for the projects."</quote>
I can't have this directories as roots for each project because for each project I can set just one CVS module

I guess that depends more on how your web server is set up than anything else. Normally it is considered good practise to keep as much as possible of the "require" files outside the web root. The path given to require is a file system path, not a web root path, so as long as you have read access, you can keep the files wherever you like. To simplify things, you can add directories to your search path by using

hth

Edit Perhaps that didn't answer your question. I don't know if there are any real advantages to using the built-in CVS client in PHPEd. I use TortoiseCVS and TortoiseSVN and they both integrate beautifully with the file tree in PHPEd. In this way you have access to all the CVS operations from the Shell Menu popup and the CVS projects are completely disconnected from the PHPEd project settings.

keeping the required files outside the web root IMO is a security risk. moreover in a chrooted environment it's not possible to access files out of your env.

For sure using tortoise is a solution, but I was suggesting to improve phhed

thanks for the suggestions

Actually not. Security risk is coming up when your scripts can be "abused" and the more scripts exposed on the web, the higher potential risk. By removing "includes" from the web tree you make potential risk lower. Although, it does not mean that the remained scripts could not be abused.


Actually... with chrooted environment, you will have to make copies of shared objects and some binaries anyway. Will you copy them into the web tree too? If not, preserve space for "includes" too

<quote>If not, preserve space for "includes" too <quote> scipts tend to require more updates then command like ls, top, cp, mv and so on


btw if you don't agree on this my request it's ok; no problem!

What frequency of updates has to do with security risk then?