Currently I just have a bunch of php files sitting in folders under source control.
Logically I have a collection of related projects and a shared database.
- Project 1 is a web application interacting with a database.
- Project 2 is some background processes also interacting with the same database.
- Project 3 is a library including extended database connection objects and other utility functions.
Project 1 and 2 depend on the library code.
I want to split the projects into three separate repositories so they can be developed independently.
What is the best approach to organising the first two projects so they depend on the library but don’t need their own copy of the library in their source tree?
Should I convert the library in to a PEAR package and have that package installed system wide.
Or is it better that projects 1 and 2 are ‘build / deployed’ in some sense and include a copy of the library during that build step. This approach would imply the use of some kind of build management tool like Phing / PHP-Maven.
Keeping a copy of the code within the source tree is not a bad thing. It allows you to control when you go through the upgrade phases rather than have the system impose it on your application. It is quite a bad situation when you need to release your code and a library change occurs just before, forcing you to make last minute changes on software that had to go live.
If you are using subversion, you can use externals to include the library code into your application and lock it at a certain revision. Updating it is just about editing a property to change the version number and update the code.
Other version control tools can offer similar functionalities. Some projects like Symfony2 also include a script to manage dependencies, however they only support git.