There are three places you're talking about:
- The Subversion repositories themselves. This is where all the source code will live. The repository will be accessible via a Subversion client which will talk to the server. The server can use the SVN protocol or HTTP/HTTPS. If you want to use HTTP/HTTPS, you'll need to setup an Apache server. If you want to run SVN, you will need to have the
svnserve
process running.
- The local working directory on the developer's system. This is where files are checked out to, and where the developer can make changes. It is not necessarily on same machine with the repository.
- The PHP Webserver. This is where the PHP files need to be in order to work and possibly to be tested.
Let's take this one at a time: With either SVN or HTTP/HTTPS, it is possible to limit who can see, checkout, and commit the code into the repository. In Subversion, you can specify this to a directory level. Thus, one developer can check in code to http://myserver/svnrepos/module1
while another can check in and out code from http://myserver/svnrepos/module2
, and neither can see your code at http://myserver/svnrepos/core
,
The tricky part is getting this information onto the server for testing. The question is how to allow developers to do commits without necessarily putting the code onto the server. There are a couple of ways to do this.
One is to create a server branch. If the developer wants the code on the PHP server, they would merge the code onto the server branch. Then, you need a mechanism to move the code from the repository to the PHP server.
I would not use a post-commit hook for this purpose. You don't want the developer to wait around for the hook to copy their code to the server. Besides, you probably want to bring the server up and down.
Instead, use a crontab which will watch the Subversion repository (especially the server branches), and then when it detects a change, take the server down, update the files in the server, and then bring the server back up. My method is to use two different directories. Have directory1 on the server. Use svn export
to export the files to directory2. Thus the server is still up. Then, take the server down, and move directory2
to directory1
, and bring the server back up. This keeps downtime to a minimum and the server in a more or less stable state.
However, you should look at Jenkins to help you with your project. Jenkins will allow you and your developers to see their changes (you can limit who sees what), do basic testing. For example, you can run PHPMD (see how messy the code is) and CPD (copy paste detector) after a commit, and Jenkins will show the results. You can then put a deploy button on Jenkins, and the developer can deploy their build to the server.
Jenkins is simple to setup and use. There are tons of plugins for various defect tracking systems, Subversion, and various testing modules. I don't know how much is available for PHP, though, but you can take a look.