CVS によるチーム・プログラミング

Concurrent Versions System (CVS) チーム・プログラミング環境では、 チーム・メンバーは、各自のワークベンチで他のメンバーから独立し、各自の作業すべてを実行します。 そして最終的には、その作業を共用することが必要になります。これは、CVS リポジトリーによって行われます。

ブランチ

CVS はブランチ・モデルを使用して、相互に独立していても依存性の高い、複数の作業をサポートします。 ブランチとは、開発チームが進行中の作業を共用して統合する場所です。 ブランチは、チーム・メンバーがプロジェクトに変更を行ったときに更新される共有ワークスペースと考えることができます。 このモデルを使用すると、各メンバーが CVS チーム・プロジェクトに取り組んで、変更が加えられたときは各自の作業を他のメンバーと共有し、 プロジェクトが進展したときには他のメンバーの作業にアクセスすることができます。 HEAD と呼ばれる特殊ブランチは、リポジトリー内のメインの作業を示します (HEAD は幹線と呼ばれることもあります)。

作業の共用

チーム・メンバーは、新しい作業を作成すると、ブランチに対する変更をコミット することにより、この作業を共用します。 同様に、最新の使用可能な作業が必要になった場合、メンバーはローカル・ワークスペースをブランチに対する変更に更新 します。  したがってブランチは、チーム・メンバーが新規作業を投入するのにつれて絶えず変化し、進展していきます。

ブランチは、プロジェクトの現在の状態を効率よく表します。 チーム・メンバーは任意の時点でブランチからワークスペースを更新し、それらが最新のものであることを確認できます。

ブランチおよびワークベンチとの対話

オプティミスティック・チーム・モデル

CVS には、チームで作業を行うために必要なフィーチャーが 2 つあります。

現行の作業と以前のドラフトを比較し、古い作業の方が良かった場合にはそれに戻すようにするためには、ヒストリーの保守が重要です。 チームの統合された作業を含む現行のプロジェクト状態の定義が 1 つ存在するようにするには、作業の調整が非常に重要です。 この調整は、ブランチ・モデルを使用して行います。

オプティミスティック・モデルとは、チームのすべてのメンバーが、アクセス権を持つ任意のリソースに変更を加えることができる場所を指します。  2 人のチーム・メンバーが同じリソースに対するブランチ変更をコミットすることができるため、競合が発生することがあり、それに対処する必要があります。 このモデルは、競合がまれにしか発生しないことを想定しているため、オプティミスティック と呼ばれます。

推奨されるワークフロー

リソースは通常、独立して存在することはありません。 一般にリソースには、他のリソースに対する暗黙または明示的な依存関係が含まれています。  たとえば、Web ページには他の Web ページへのリンクが含まれており、 ソース・コードは他のソース・コードのリソースに記述されている ART ファイルを参照します。  どのようなリソースも孤立しているわけではありません。

リソースがブランチにコミットされると、これらの依存関係は影響を受けます。 ブランチは現行プロジェクトの状態を表しているため、依存関係の整合性を保証することが重要になります。 このような場合、どの時点でも、チームのメンバーはブランチの内容を新規作業の基礎とすることができます。

したがって、ブランチの整合性が維持されているワークフローが理想的なワークフローになります。

理想的な列挙フロー

理想的なワークフローは、次のように進行します。

  1. 更新を開始します。 作業を開始する前に、現行のブランチ状態によってワークスペース内のリソースを更新します。 注意するべきローカル作業がないことが確実であれば、必要なプロジェクトをブランチ (または HEAD) から選択し、 「プロジェクトとしてチェックアウト」(プロジェクトがすでにローカルに存在している場合、 または「置換」>「リポジトリーから最新」を選択するのが、最も早いキャッチアップ方法です。 これで、ブランチのリソースによってローカル・リソースが上書きされます。

  2. 変更を加えます。 各自のワークベンチでローカルに作業を行い、新規リソースを作成して既存のリソースを変更し、ローカルに保存します。

  3. 同期化します。 作業をコミットする準備ができたら、リポジトリーと同期化します。

    1. 更新します。 新しい変更を調べ、各自のローカル・ワークベンチに追加します。 これで、変更が、リリースしようとしている内容の整合性に影響を与える可能性があるかどうかを判断することができます。 競合を解決します。 再テスト、つまり整合性のチェック・プログラムを実行します (例えば、ハイパーテキストのリンクが壊れていないかどうか調べたり、コードがコンパイルされるかを確認するなど)。

    2. コミットします。 変更内容が最新のブランチの内容と正しく統合されることが確認できたら、ブランチに変更をコミットします。 新しい変更があった場合は、慎重を期してステップ 4 を繰り返します。

もちろん、これは理想的な ワークフローです。 新しい変更による影響がないことが確実な場合、更新しないでコミットすることができます。 ただし通常は、チームのメンバーは上記のようなフローに従って、ブランチの整合性が誤って危険にさらされることがないようにする必要があります。 

CVS の詳細については、http://www.cvshome.org. を参照してください。

関連概念
CVS リポジトリー
ブランチ
バージョン
CVS リポジトリーとの同期化

関連タスク
CVS リポジトリー・ロケーションの作成

プロジェクトを CVS リポジトリーからチェックアウト
 
ワークベンチでリソースを置換

CVS を使用する新規プロジェクトの共用

リポジトリーとの同期化

更新

競合の解決

ブランチからマージする

コミット

関連参照
CVS

Copyright IBM Corporation and others 2000, 2003. All Rights Reserved.