Concurrent Versions System (CVS) チーム・プログラミング環境では、 チーム・メンバーは、各自のワークベンチで他のメンバーから独立し、各自の作業すべてを実行します。 そして最終的には、その作業を共用することが必要になります。これは、CVS リポジトリーによって行われます。
CVS はブランチ・モデルを使用して、互いに分離はしていても相互依存性の高い作業を、 複数進行できるようにサポートします。 ブランチとは、開発チームが進行中の作業を共用して統合する場所です。 ブランチは、チーム・メンバーがプロジェクトに変更を行ったときに更新される共有ワークスペースと考えることができます。 このモデルを使用すると、各メンバーが CVS チーム・プロジェクトに取り組んで、変更が加えられたときは各自の作業を他のメンバーと共有し、 プロジェクトが進展したときには他のメンバーの作業にアクセスすることができます。 HEAD と呼ばれる特殊ブランチは、リポジトリー内のメインの作業を示します (HEAD は幹線と呼ばれることもあります)。
チーム・メンバーは、新しい作業を作成すると、ブランチに対する変更をコミット することにより、この作業を共用します。 同様に、使用可能な最新の作業を取得しようとする場合、メンバーはローカル・ワークスペースをブランチ上の変更に更新 します。 このようにブランチは、チーム・メンバーが新規作業を発信するのにつれて絶えず変化し、進化していきます。
ブランチは、プロジェクトの現在の状態を効率よく表します。 チーム・メンバーは任意の時点でブランチからワークスペースを更新し、それらが最新のものであることを確認できます。
CVS には、チームで作業を行うために必要なフィーチャーが 2 つあります。
チームによって発信された作業のヒストリー
この作業を調整して統合する方法
現行の作業と以前のドラフトを比較し、古い作業の方が良かった場合にはそれに戻すようにするためには、ヒストリーの保守が重要です。 チームの統合された作業を含む現行のプロジェクト状態の定義が 1 つ存在するようにするには、作業の調整が非常に重要です。 この調整は、ブランチ・モデルを使用して行います。
オプティミスティック・モデルとは、チームのすべてのメンバーが、アクセス権を持つ任意のリソースに変更を加えることができる場所を指します。 2 人のチーム・メンバーが同じリソースに対するブランチ変更をコミットすることができるため、競合が発生することがあり、それに対処する必要があります。 このモデルは、競合がまれにしか発生しないことを想定しているため、オプティミスティック と呼ばれます。
リソースは通常、独立して存在することはありません。 一般にリソースには、他のリソースに対する暗黙または明示的な依存関係が含まれています。 例えば、Web ページには他の Web ページへのリンクが含まれており、 ソース・コードには、他のソース・コードのリソースに記述されている成果物への参照があります。 どのようなリソースも孤立しているわけではありません。
リソースがブランチにコミットされると、これらの依存関係は影響を受けます。 ブランチは現行プロジェクトの状態を表しているため、依存関係の整合性を保証することが重要になります。 このような場合、どの時点でも、チームのメンバーはブランチの内容を新規作業の基礎とすることができます。
したがって、ブランチの整合性が維持されているワークフローが理想的なワークフローになります。
理想的なワークフローは、次のように進行します。
更新を開始します。 作業を開始する前に、現行のブランチ状態によってワークスペース内のリソースを更新します。 注意すべきローカル作業がないことが確実であれば、必要なプロジェクトをブランチ (または HEAD) から選択し、「チェックアウト」(もしくは、プロジェクトが既にローカルに存在 している場合、「置換」>「リポジトリーから最新」) を選択するのが、最も早いキャッチアップ方法です。 これで、ブランチのリソースによってローカル・リソースが上書きされます。
変更を加えます。 各自のワークベンチでローカルに作業を行い、新規リソースを作成して既存のリソースを変更し、ローカルに保存します。
同期化します。 作業をコミットする準備ができたら、リポジトリーと同期化します。
更新します。 着信変更を調べ、各自のローカル・ワークベンチに追加します。 これで、変更が、コミットしようとしている内容の整合性に影響を与える可能性があるかどうかを判断することができます。 競合を解決します。 再テスト、つまり整合性の検査プログラムを実行します (例えば、ハイパーテキストのリンクが壊れていないかどうか調べたり、コードがコンパイルされるかを確認するなど)。
コミットします。 変更内容が最新のブランチの内容と正しく統合されることが確認できたら、ブランチに変更をコミットします。 慎重を期すために、新しい着信変更があった場合は前のステップを繰り返します。
もちろん、これは理想的な ワークフローです。 着信変更による影響がないことが確実な場合、更新しないでコミットすることができます。 ただし通常は、チームのメンバーは上記のようなフローに従って、ブランチの整合性が誤って危険にさらされることがないようにする必要があります。
CVS の詳細については、https://www.cvshome.org を参照してください。
CVS リポジトリー
ブランチ
バージョン
CVS リポジトリーとの同期化
CVS リポジトリー・ロケーションの作成
CVS リポジトリーからのプロジェクトのチェックアウト
ワークベンチ内のリソースの置換
CVS を使用する新規プロジェクトの共用
リポジトリーとの同期化
更新
競合の解決
ブランチからマージする
コミット