あなたが話している場所は3つあります：
- Subversion リポジトリ自体。これは、すべてのソース コードが存在する場所です。リポジトリは、サーバーと通信する Subversion クライアントを介してアクセスできます。サーバーはSVNプロトコルまたはHTTP/HTTPSを使用できます。HTTP/HTTPSを使用する場合は、Apache サーバーをセットアップする必要があります。SVNを実行する場合は、
svnserveプロセスを実行する必要があります。
- 開発者のシステム上のローカル作業ディレクトリ。これは、ファイルがチェックアウトされる場所であり、開発者が変更を加えることができる場所です。必ずしもリポジトリと同じマシン上にあるとは限りません。
- PHP ウェブサーバー。これは、動作し、場合によってはテストするために、PHP ファイルが必要な場所です。
1 つずつ見ていきましょう: SVNまたはHTTP/HTTPSを使用すると、誰がコードを表示、チェックアウト、およびリポジトリにコミットできるかを制限できます。Subversion では、これをディレクトリ レベルで指定できます。したがって、ある開発者は にコードをチェックインhttp://myserver/svnrepos/module1でき、別の開発者は からコードをチェックインおよびチェックアウトhttp://myserver/svnrepos/module2でき、どちらも でコードを見ることはできませんhttp://myserver/svnrepos/core。
トリッキーな部分は、テストのためにこの情報をサーバーに取得することです。問題は、必ずしもコードをサーバーに置くことなく、開発者がコミットできるようにする方法です。これを行うにはいくつかの方法があります。
1 つは、サーバーブランチを作成することです。開発者が PHP サーバー上のコードを必要とする場合、コードをサーバーブランチにマージします。次に、コードをリポジトリから PHP サーバーに移動するメカニズムが必要です。
この目的でコミット後のフックを使用することはありません。開発者がフックによってコードがサーバーにコピーされるのを待つ必要はありません。さらに、おそらくサーバーを起動したり停止したりしたいと思うでしょう。
代わりに、Subversion リポジトリ (特にサーバーブランチ) を監視する crontab を使用し、変更を検出したら、サーバーを停止し、サーバー内のファイルを更新してから、サーバーを再起動します。私の方法は、2 つの異なるディレクトリを使用することです。サーバー上に directory1 があります。svn exportファイルを directory2 にエクスポートするために使用します。したがって、サーバーはまだ稼働しています。次に、サーバーを停止して に移動directory2しdirectory1、サーバーを再起動します。これにより、ダウンタイムが最小限に抑えられ、サーバーは多かれ少なかれ安定した状態になります。
ただし、プロジェクトを支援するためにJenkinsを検討する必要があります。Jenkins を使用すると、開発者は自分の変更を確認し (誰が何を表示するかを制限できます)、基本的なテストを行うことができます。たとえば、コミット後にPHPMD (コードの乱雑さを確認) とCPD (コピー ペースト検出器) を実行すると、Jenkins が結果を表示します。次に、 Jenkins にデプロイボタンを配置すると、開発者はビルドをサーバーにデプロイできます。
Jenkins はセットアップと使用が簡単です。さまざまな欠陥追跡システム、Subversion、さまざまなテスト モジュール用のプラグインがたくさんあります。ただし、PHP でどれだけ利用できるかはわかりませんが、ぜひご覧ください。