(57)【要約】【課題】複数の作業者が並行開発している複数のノードから構成されるソースファイルを効率よく管理することができるソース構成管理方法を提供する。【解決手段】管理サーバ装置１００からダウンロードしたソースファイルについて、クライアント装置２００のテスト実行処理部２２１が作業者が変更したノードを含むソースファイルをテストをする際に、実行ノード記録処理部２２２がテストで実行したノードの経路情報（変更に伴う影響範囲）を記録し、アップロード処理部２２５がノードの経路情報を添付して変更したソースファイルのアップロード要求を管理サーバ装置１００にする。管理サーバ装置１００は、競合検出処理部１２２が該変更に伴う影響範囲を他の作業者が変更加えていなかった場合に競合がないと判定し、構成管理処理部１２１がマスタソースに変更したソースファイルの統合をする。【選択図】図１
2012230636.tif 000002
【特許請求の範囲】
【請求項１】
複数のクライアントと管理サーバとを有するシステムにおいて、
前記クライアントは、ファイル名を指定して複数のノードから構成されるソースファイルのダウンロードを前記管理サーバに要求し、前記ダウンロードしたソースファイルのノードについて作業者により変更されたソースファイルのテストをし、前記テストの際に前記変更されたノードを含むノードの経路情報を実行ノード情報として記録し、前記記録された実行ノード情報とともに前記変更したソースファイルを前記管理サーバにアップロード要求を行うことにより、前記ソースファイルを複数の前記作業者が並行して変更する際に、前記変更されたソースファイルの構成を管理するソース構成管理方法であって、
前記管理サーバは、
記憶部に、ファイル名とクライアント名と版番とを関連付けた配布管理情報と、ファイル名と版番と変更されたノードとを関連付けた変更管理情報とが記憶されており、
前記管理サーバは、
前記クライアントからアップロード要求があった場合、前記クライアント名および前記ファイル名に基づいて前記配布管理情報から前記クライアントに配布したソースファイルの版番を取得し、前記取得した版番のソースファイルと前記変更したソースファイルとを比較して変更されたノードを抽出し、前記変更されたノードが前記変更管理情報に基づいて既に変更されたノードと競合があるか否かの競合判定をし、前記競合判定で競合がない場合、前記変更されたノードを前記最新の版番のソースファイルと統合するとともに、変更した情報を前記変更管理情報に記録し、
前記競合判定の際に、前記変更管理情報を参照して、前記クライアントに配布した版番より新しい履歴にある既に変更された既変更ノードを取得し、前記変更されたノードが前記既変更ノードに含まれるか否かを判定し、前記既変更ノードに含まれない場合、前記既変更ノードが、前記実行ノード情報に含まれているか否かを判定し、前記実行ノード情報に含まれていない場合、前記競合判定を競合がないと判定する
ことを特徴とするソース構成管理方法。
【請求項２】
前記管理サーバは、前記クライアントからダウンロード要求があった場合、前記変更管理情報から前記指定されたファイル名の最新の版番を特定し、前記特定された版番のソースファイルを要求元の前記クライアントに配布するとともに、前記配布した情報を含むダウンロード要求のエントリを前記配布管理情報に記録する
ことを特徴とする請求項１に記載のソース構成管理方法。
【請求項３】
前記管理サーバは、前記競合判定で競合がないと判定し前記変更されたノードを前記最新の版番のソースファイルと統合した場合、前記アップロード要求があったクライアントについて前記ダウンロード要求のエントリを前記配布管理情報から削除する
ことを特徴とする請求項２に記載のソース構成管理方法。
【請求項４】
前記管理サーバは、前記クライアントからアップロード要求があった場合、かつ、前記配布管理情報に前記要求元のクライアントの前記ダウンロード要求のエントリがない場合、前記要求元のクライアントに再ダウンロード要求をする旨の通知をする
ことを特徴とする請求項３に記載のソース構成管理方法。
【請求項５】
前記管理サーバは、前記競合判定の際に、前記競合判定を競合すると判定した場合、前記アップロード要求のクライアントに、アップロードが失敗した旨を通知する
ことを特徴とする請求項１に記載のソース構成管理方法。
【請求項６】
前記ノードは、前記ノードの機能を実現できる複数のステップのコードを含んでおり、
前記ノード内のステップコードの競合判定を行う際には、
前記管理サーバは、前記記憶部に、ファイル名と版番と変更されたステップとを関連づけた前記変更管理情報が記憶されており、
前記実行ノード情報は、前記変更されたステップの経路情報である
ことを特徴とする請求項１に記載のソース構成管理方法。
【請求項７】
複数のクライアントと管理サーバとを有するシステムにおいて、
前記クライアントは、ファイル名を指定して複数のノードから構成されるソースファイルのダウンロードを前記管理サーバに要求し、前記ダウンロードしたソースファイルのノードについて作業者により変更されたソースファイルのテストをし、前記テストの際に前記変更されたノードを含むノードの経路情報を実行ノード情報として記録し、前記記録された実行ノード情報とともに前記変更したソースファイルを前記管理サーバにアップロード要求を行うことにより、前記ソースファイルを複数の前記作業者が並行して変更する際に、前記変更されたソースファイルの構成を管理するソース構成管理プログラムであって、
コンピュータに、
記憶部に、ファイル名とクライアント名と版番とを関連付けた配布管理情報と、ファイル名と版番と変更されたノードとを関連付けた変更管理情報とを記憶する処理と、
前記クライアントからアップロード要求があった場合、前記クライアント名および前記ファイル名に基づいて前記配布管理情報から前記クライアントに配布したソースファイルの版番を取得し、前記取得した版番のソースファイルと前記変更したソースファイルとを比較して変更されたノードを抽出し、前記変更されたノードが前記変更管理情報に基づいて既に変更されたノードと競合があるか否かの競合判定をし、前記競合判定で競合がない場合、前記変更されたノードを前記最新の版番のソースファイルと統合するとともに、変更した情報を前記変更管理情報に記録する構成管理処理と、
前記競合判定の際に、前記変更管理情報を参照して、前記クライアントに配布した版番より新しい履歴にある既に変更された既変更ノードを取得し、前記変更されたノードが前記既変更ノードに含まれるか否かを判定し、前記既変更ノードに含まれない場合、前記既変更ノードが、前記実行ノード情報に含まれているか否かを判定し、前記実行ノード情報に含まれていない場合、前記競合判定を競合がないと判定する競合判定処理とを
実行させるためのソース構成管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の作業者が並行開発している複数のノードから構成されるソースファイル（ソースプログラム）を効率よく管理することができるソース構成管理方法およびソース構成管理プログラムに関する。
【背景技術】
【０００２】
従来、複数の作業者が並行開発しているソースファイルは、ある作業者がプログラムを修正する場合、修正箇所を指定している間、他の作業者はプログラムのソースファイルへのアクセスに対してロックし、他の作業者が修正できないように排他処理を行っていた（例えば、特許文献１参照）。
【０００３】
また、各作業者の端末から、同一のソースファイルを１行修正するたびにソースコード変更履歴管理装置に対してデータ送信を行い、他の作業者が同一のファイルの同一の行の修正を行っているか否かをチェックする方法もある（例えば、特許文献２参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００５−１６５６９８号公報
【特許文献２】特開平１０−３４１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１の場合、修正箇所を指定する際に、プログラムのどこを修正するのかを修正作業を開始する前に確定する必要があるが、熟練した作業者でなければ、短時間で修正箇所を確定することができない問題がある。また、修正箇所の確定が完了するまでは、ソースファイルにロックがかかった状態となり、他の作業者が作業できない問題がある。
【０００６】
特許文献２の場合、他の作業者が実施している作業内容を把握できる利点はある。しかしながら、基本的には、他の作業者が同一のソースファイルを修正していると認識しているとわかった場合、その作業が終わるのを待ってから自分の修正をいれるのが通常の流れである。
【０００７】
従来から、作業者には、他の作業者の開発状況に関わらずもっと自由に開発に専念したいという要望があるが、管理者にとっては、ソースファイルの版番（バージョン）管理が大変であり効率よい管理方法が望まれていた。また、同じソースファイルを複数の作業者で修正した場合、自動的に統合する方法が望まれていた。管理者には、変更内容を統合するための専門知識と作業時間が要求され、統合に失敗することもよくあった。
【０００８】
本発明は、前記の課題を解決するための発明であって、複数の作業者が並行開発している複数のノードから構成されるソースファイルを効率よく管理することができるソース構成管理方法およびソース構成管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
前記目的を達成するため、本発明のソース構成管理方法は、複数のクライアントと管理サーバとを有するシステムにおいて、複数のノードから構成されるソースファイルを複数の作業者が並行して変更する際に、変更されたソースファイルの構成を管理するソース構成管理方法である。
【００１０】
クライアントは、ファイル名を指定してソースファイルのダウンロードを管理サーバに要求し、ダウンロードしたソースファイルのノードについて作業者により変更されたソースファイルのテストをし、テストの際に変更されたノードを含むノードの経路情報を実行ノード情報（例えば、実行ノードテーブル２２７）として記録し、記録された実行ノード情報とともに変更したソースファイルとを管理サーバにアップロード要求をする。
【００１１】
管理サーバには、記憶部に、ファイル名とクライアント名と版番とを関連付けた配布管理情報（例えば、配布管理テーブル１２６）と、ファイル名と版番と変更されたノードとを関連付けた変更管理情報（例えば、変更管理テーブル１２７）とが記憶されている。
【００１２】
管理サーバは、クライアントからアップロード要求があった場合、クライアント名およびファイル名に基づいて配布管理情報からクライアントに配布したソースファイルの版番を取得し、取得した版番のソースファイルと変更したソースファイルとを比較して変更されたノードを抽出し、変更されたノードが変更管理情報に基づいて既に変更されたノードと競合があるか否かの競合判定をし、競合判定で競合がない場合、変更されたノードを最新の版番のソースファイルと統合するとともに、変更した情報を変更管理情報に記録する。
【００１３】
競合判定の際に、変更管理情報を参照して、クライアントに配布した版番より新しい履歴にある既に変更された既変更ノードを取得し、変更されたノードが既変更ノードに含まれるか否かを判定し、既変更ノードに含まれない場合、既変更ノードが、実行ノード情報に含まれているか否かを判定し、実行ノード情報に含まれていない場合、競合判定を競合がないと判定することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、複数の作業者が並行開発している複数のノードから構成されるソースファイルを効率よく管理することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施形態に係るソース構成管理システムの構成を示す図である。
【図２】ソース構成管理システムの処理概要を示す図である。
【図３】クライアント装置によるソースファイルの変更と統合可否を示す図である。
【図４】配布管理テーブルの一例を示す図である。
【図５】変更管理テーブルの一例を示す図である。
【図６】実行ノードテーブルの一例を示す図である。
【図７】構成管理処理部のクライアントからのダウンロード要求処理を示すフローチャートである。
【図８】構成管理処理部のクライアントからのアップロード要求処理を示すフローチャートである。
【図９】競合検出処理部の競合検出処理を示すフローチャートである。
【図１０】実行ノード記録処理部によるサンプルプログラムのノード番号の採番を示す図である。
【図１１】実行ノード記録処理部によるサンプルプログラムの実行ノード記録例を示す図であり、（ａ）は実行ノードテーブルの例であり、（ｂ）は複数のソースプログラムを同時にテストした場合の実行ノードテーブルの例である。
【図１２】実施例１の変更元が最新版のため既存ノード変更のアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態、（ｅ）はアップロード後の配布管理テーブルの状態を示す。
【図１３】実施例１において、（ａ）は版番１に基づいたクライアントＡによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番２のマスタの状態を示す図である。
【図１４】実施例２の変更管理テーブルの変更部位と同じ既存ノード変更でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。
【図１５】実施例２において、（ａ）はアップロード前の版番２のマスタの状態を示す図であり、（ｂ）は版番１に基づいたクライアントＡによる変更と実行ノードを説明する図である。
【図１６】実施例３の変更管理テーブルの変更部位と同じ既存ノード削除でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。
【図１７】実施例３において、（ａ）はアップロード前の版番２のマスタの状態を示す図であり、（ｂ）は版番１に基づいたクライアントＢによる変更と実行ノードを説明する図である。
【図１８】実施例４の変更管理テーブルの変更部位と競合しない既存ノード変更でアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態、（ｅ）はアップロード後の配布管理テーブルの状態を示す。
【図１９】実施例４において、（ａ）は版番１に基づいたクライアントＢによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番３のマスタの状態を示す図である。
【図２０】実施例５の変更管理テーブルの変更部位と同じ既存ノード変更でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。
【図２１】実施例５において、（ａ）はアップロード前の版番３のマスタの状態を示す図であり、（ｂ）は版番１に基づいたクライアントＣによる変更と実行ノードを説明する図である。
【図２２】実施例６のマスタの再取得により変更管理テーブルの変更部位と競合しない既存ノード変更でアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態、（ｅ）はアップロード後の配布管理テーブルの状態を示す。
【図２３】実施例６において、（ａ）は版番３に基づいたクライアントＣによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番４のマスタの状態を示す図である。
【図２４】実施例７の変更管理テーブルの変更部位と競合する新規ノード追加でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。
【図２５】実施例７において、（ａ）はアップロード前の版番４のマスタの状態を示す図であり、（ｂ）は版番２に基づいたクライアントＡによる変更と実行ノードを説明する図である。
【図２６】実施例８のマスタの再取得により新規ノード追加でアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態を示す。
【図２７】実施例８において、（ａ）は版番４に基づいたクライアントＡによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番５のマスタの状態を示す図である。
【図２８】実施例９の変更管理テーブルの変更部位と競合する既存ノード削除でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。
【図２９】実施例９において、（ａ）はアップロード前の版番５のマスタの状態を示す図であり、（ｂ）は版番３に基づいたクライアントＢによる変更と実行ノードを説明する図である。
【図３０】実施例１０のマスタの再取得により既存ノード削除でアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態を示す。
【図３１】実施例１０において、（ａ）は版番５に基づいたクライアントＢによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番６のマスタの状態を示す図である。
【図３２】構成管理処理部のクライアントからの他のアップロード要求処理を示すフローチャートである。
【図３３】（ａ）は複数のソースファイルが親子の関係にある場合の実行ノードテーブルを示す図であり、（ｂ）は、呼び出し元から変更対象のソースファイルの実行ノードを説明する図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施形態を図面に基づいて詳細に説明する。
図１は、本発明の実施形態に係るソース構成管理システムの構成を示す図である。ソース構成管理システムは、ソースファイルを管理する管理サーバ装置１００（管理サーバ）と、複数のクライアント装置２００（クライアント）を含んで構成され、管理サーバ装置１００とクライアント装置２００とは、ネットワーク３００で接続されている。
【００１７】
管理サーバ装置１００は、ＣＰＵ１１０、メモリ１２０（記憶部）、ＨＤＤ１３０、ＮＩＣ１４０を有し、システムバス１５０を介して接続されている。メモリ１２０には、ＯＳ１２３のほか、複数のソースファイルからなるマスタソースの構成を管理する構成管理処理部１２１（図７、図８参照）、作業者が変更したソースファイルの部位が他の作業者の変更部位と競合するか否かを検出する競合検出処理部１２２（図９参照）、配布管理テーブル１２６（図４参照）、変更管理テーブル１２７（図５参照）が格納されている。ＨＤＤ１３０には、マスタソースである複数のソースファイルが格納されている。なお、ＣＰＵはCentral Processing Unitの略、ＨＤＤはHard Disk Driveの略、ＮＩＣはNetwork Interface Cardの略である。
【００１８】
クライアント装置２００は、ＣＰＵ２１０、メモリ２２０、ＨＤＤ２３０、ＮＩＣ２４０を有し、システムバス２５０を介して接続されている。メモリ２２０には、ＯＳ２２３のほか、変更した部位を含む経路をテスト実行するテスト実行処理部２２１、変更した部位を含む経路の部位の識別情報を記録する実行ノード記録処理部２２２、ユーザがソースファイルを変更するための編集部２２６、ソースファイルを管理サーバ１００からダウンロードするダウンロード処理部２２４、変更したソースファイルをアップロードするアップロード処理部２２５、および実行ノードテーブル２２７（図６参照）が格納される。ＨＤＤ２３０には、変更対象となるソースファイルが格納される。
【００１９】
なお、アップロードとは、ネットワーク３００を通じて、クライアント装置２００に保存されているデータを管理サーバ装置１００に転送することを意味し、逆をダウンロードという。また、ソースファイルは、複数の部位（以下、ノードと称する。）から構成されており、各ノードは、ノードの機能を実現できる複数のステップコードを含んでいる。
【００２０】
図２は、ソース構成管理システムの処理概要を示す図である。図２を参照して、ソース構成管理システムの処理概要を説明する。主要な箇所にステップ符号を付加している。
＜ダウンロードに係る処理概要＞
（１）管理サーバ装置１００は、クライアント装置２００のダウンロード処理部２２４からソースファイルのダウンロード要求（配布要求）があると、構成管理処理部１２１は、マスタソースの最新版をＨＤＤ１３０から取り出し要求元のクライアント装置２００に配布する（ステップＳ１）。また、構成管理処理部１２１は、配布に関する情報を配布管理テーブル１２６に記録する（ステップＳ２）。
（２）クライアント装置２００の編集部２２６は、配布されたソースファイルを変更後、コンパイルしてオブジェクトにする（ステップＳ３）。
（３）クライアント装置２００のテスト実行処理部２２１は、テスト環境でオブジェクトのテスト実行の際、実行ノード記録処理部２２２を呼び出す（ステップＳ４）。テスト実行処理部２２１は、変更ノードの妥当性を確認するため、既存のノードを変更した場合は、変更したノードを経路とするソースファイルのテストを実行する。既存のノードを削除した場合は、削除ノードに伴う他のノードを経路とするソースファイルのテスト実行する。
（４）クライアント装置２００の実行ノード記録処理部２２２は、テスト実行されたノードを経路情報の形で実行ノードテーブル２２７に記録する（ステップＳ５）。
【００２１】
＜アップロードに係る処理概要＞
（５）クライアント装置２００のアップロード処理部２２５は、実行ノードテーブル２２７を添えて変更済みソースファイルをアップロード要求する（ステップＳ６）。
（６）管理サーバ装置１００の構成管理処理部１２１は、アップロード要求を受理すると、競合検出処理部１２２を呼び出す（ステップＳ７）。
（７）競合検出処理部１２２は、変更管理テーブル１２７と受理した実行ノードテーブル２２７を参照し、他の作業者が既に変更したノードと競合しないか否かの競合の有無を判定し、判定結果を構成管理処理部１２１に通知する（ステップＳ８）
（８）構成管理処理部１２１は、判定結果に競合がない場合、アップロードを許可し、変更済みソースファイルの内容を最新版のマスタソースに統合し更新する（ステップＳ９）。また、構成管理処理部１２１は、変更管理テーブル１２７にマスタソースの変更ノードの識別情報などを記録する（ステップＳ１０）。以上、図２においてソース構成管理システムの処理概要を示したが、具体的なソースファイルを例に、変更済みソースファイルの内容を最新版のマスタソースに統合できるか否かについて、図３を参照して説明する。
【００２２】
図３は、クライアント装置によるソースファイルの変更と統合可否を示す図である。ソースファイルは、図３に示すノードＮ１からノードＮ８を有して構成されているとする。複数のクライアント装置２００であるクライアントＡ、クライアントＢ、クライアントＣにおいて、ほぼ同時にソースファイルを変更した場合について考える。具体的には、クライアントＡは、ノードＮ３を変更し、クライアントＢはノードＮ４を変更し、クライアントＣは、ノードＮ６を変更した。
【００２３】
前記の変更の場合、例えば、クライアントＡ、クライアントＢ、クライアントＣにおいて、変更ノードの妥当性を確認するための実行ノードテーブル２２７には、テスト実行ノードとして下記の妥当性の確認に必要な１以上の経路情報が記録される。なお、括弧書きが変更ノードを示す。
クライアントＡの場合：ノードＮ１，Ｎ２，（Ｎ３），Ｎ５，Ｎ６，Ｎ８
ノードＮ１，Ｎ２，（Ｎ３），Ｎ５，Ｎ７，Ｎ８
なお、ノードＮ３を変更した場合、ノードＮ５で分岐があるので、２つの経路情報が記録される。
クライアントＢの場合：ノードＮ１，Ｎ２，（Ｎ４），Ｎ５，Ｎ６，Ｎ８
ノードＮ１，Ｎ２，（Ｎ４），Ｎ５，Ｎ７，Ｎ８
なお、ノードＮ４を変更した場合、ノードＮ５で分岐があるので、２つの経路情報が記録される。
クライアントＣの場合：ノードＮ１，Ｎ２，Ｎ３，Ｎ５，（Ｎ６），Ｎ８
ノードＮ１，Ｎ２，Ｎ４，Ｎ５，（Ｎ６），Ｎ８
なお、ノードＮ６を変更した場合、ノードＮ２で分岐があるので、２つの経路情報が記録される。
【００２４】
競合検出処理部１２２は、クライアントＡのノードＮ３の変更が先にマスタソースに統合されていた場合において、クライアントＢの実行ノードテーブル２２７には、ノードＮ３が含まれていないため、競合しないと判定する。同様に、クライアントＢのノードＮ４の変更が先にマスタソースに統合されていた場合において、クライアントＡの実行ノードテーブル２２７には、ノードＮ４が含まれていないため、競合しないと判定する。
【００２５】
競合検出処理部１２２は、クライアントＡのノードＮ３の変更が先にマスタソースに統合されていた場合において、クライアントＣの実行ノードテーブル２２７には、ノードＮ３が含まれているため、競合すると判定する。同様に、クライアントＣのノードＮ６の変更が先にマスタソースに統合されていた場合において、クライアントＡの実行ノードテーブル２２７には、ノードＮ６が含まれているため、競合すると判定する。
【００２６】
また、競合検出処理部１２２は、クライアントＢのノードＮ４の変更が先にマスタソースに統合されていた場合において、クライアントＣの実行ノードテーブル２２７には、ノードＮ４が含まれているため、競合すると判定する。同様に、クライアントＣのノードＮ６の変更が先にマスタソースに統合されていた場合においても、クライアントＢの実行ノードテーブル２２７には、ノードＮ６が含まれているため、競合すると判定する。
【００２７】
図３に示す例の場合、クライアントＡ，Ｂ，Ｃで同時に変更した場合に、クライアントＡとクライアントＢの変更は競合しないため統合可能、クライアントＡとクライアントＣ、または、クライアントＢとクライアントＣの変更は競合するため統合不可能と機械的に判断し、並行開発における統合を容易にするものである。
【００２８】
本実施形態では、クライアント装置２００でプログラムを変更した際のテストで実行したノードに着目し、その実行ノードが最新版のマスタソースでも変化されていない場合は、クライアント装置２００でのテストが有効なものとみなし、クライアント装置２００の変更内容をマスタに統合することができる。
【００２９】
図３の例を参照して、例えばクライアントＡ→Ｂ→Ｃの順で変更内容を統合しようとしたとすると下記のような結果になる。
（Ａ１）マスタソースには他の変更が統合されていないため、クライアントＡの変更を統合できる。マスタソースにクライアントＡの変更が統合される。
（Ａ２）マスタソースにはクライアントＡの変更が統合されているが、変更部位がクライアントＢの実行ノードテーブル２２７と競合しないため、クライアントＢのテストは最新版のマスタソースに対しても有効である。クライアントＢの変更はクライアントＡの変更と統合できる。マスタソースにはクライアントＡの変更に加えて、クライアントＢの変更が統合される。
（Ａ３）マスタソースにはクライアントＡとＢの変更が統合されている。変更部位がクライアントＣのテスト実行ノードと競合するため、クライアントＣのテストは最新版のマスタソースに対して有効ではない。クライアントＣの変更はマスタソースに統合できない。なお、統合できなかったクライアントＣは、再度マスタソースを取得しなおした上、変更およびテストを実行する必要がある。
【００３０】
また、図３の例を参照して、クライアントＣ→Ａ→Ｂの順で変更内容を統合しようとしたとすると下記のような結果になる。
（Ｃ１）マスタソースには他の変更が統合されていないため、クライアントＣの変更を統合できる。マスタソースにクライアントＣの変更が統合される。
（Ｃ２）マスタソースにはクライアントＣの変更が統合されている。変更部位がクライアントＡのテスト実行ノードと競合するため、クライアントＡのテストは最新版のマスタソースに対して有効ではない。クライアントＡの変更はマスタソースに統合できない。なお、統合できなかったクライアントＡは、再度マスタソースを取得しなおした上、変更およびテストを実行する必要がある。
（Ｃ３）マスタソースにはクライアントＣの変更が統合されている。変更部位がクライアントＢのテスト実行ノードと競合するため、クライアントＢのテストは最新版のマスタソースに対して有効ではない。クライアントＢの変更はマスタソースに統合できない。なお、統合できなかったクライアントＢは、再度マスタソースを取得しなおした上、変更およびテストを実行する必要がある。
【００３１】
本実施形態によれば、ソースファイルの変更を確認するため、テスト実行処理部２２１で実行したノードの経路情報（変更に伴う影響範囲）を実行ノード記録処理部２２２が記録し、競合検出処理部１２２は、該変更に伴う影響範囲を他の作業者が変更加えていなかった場合に競合がないと判定することができる。
【００３２】
次に各種テーブルについて説明する。
図４は、配布管理テーブルの一例を示す図である。配布管理テーブル１２６は、ファイル名４１、クライアント名４２、および版番４３を含んで構成される。具体的には、図４を参照すると、クライアントＡは、ファイル名「ｓｏｕｒｃｅ１．ｃ」の版番１をダウンロードしていることがわかる。同様に、クライアントＢも、ファイル名「ｓｏｕｒｃｅ１．ｃ」の版番１をダウンロードしていることがわかる。クライアントＣは、ファイル名「ｓｏｕｒｃｅ１．ｃ」の版番３をダウンロードしていることがわかる。
【００３３】
図５は、変更管理テーブルの一例を示す図である。変更管理テーブル１２７は、ファイル名５１、版番５２、および変更部位５３を含んで構成される。変更部位５３は、その版番で変更された部位を示し、マスタソースとしては、最新の版番までの変更部位が考慮される。具体的には、図５を参照すると、ファイル名「ｓｏｕｒｃｅ１．ｃ」の版番１は、変更部位が記録されていない状態である。ファイル名「ｓｏｕｒｃｅ１．ｃ」の版番２は、変更部位としてノードＮ３があり、ファイル名「ｓｏｕｒｃｅ１．ｃ」の版番３は、変更部位としてノードＮ４であるとわかる。図５に示す例の場合、マスタソースのファイル名「ｓｏｕｒｃｅ１．ｃ」の版番３には、ノードＮ３とノードＮ４の変更がされていることを意味する。
【００３４】
図６は、実行ノードテーブルの一例を示す図である。実行ノードテーブル２２７は、ファイル名６１および実行ノード６２を含んで構成される。実行ノードには、図３で既に、説明した経路情報が記録されている。図６の場合は、図３で示したクライアントＣの場合である。
【００３５】
次に各処理フローについて説明する。
図７は、構成管理処理部のクライアントからのダウンロード要求処理を示すフローチャートである。適宜図１を参照して説明する。構成管理処理部１２１は、クライアント装置２００からのダウンロード要求があると、ダウンロード要求に含まれるクライアント名とファイル名を取得し（ステップＳ７０１）、ＨＤＤ１３０（ディスク）から該ファイル名のソースファイルの最新版を取得する（ステップＳ７０２）。
【００３６】
構成管理処理部１２１は、配布情報として図４に示す配布管理テーブル１２６にファイル名４１とクライアント名４２と版番４３を記録し（ステップＳ７０３）、要求元のクライアント装置２００にソースファイルを配布し（ステップＳ７０４）、処理を終了する。なお、ステップＳ７０３とステップＳ７０４の処理については、順序が入れ替わってもよい。
【００３７】
図８は、構成管理処理部のクライアントからのアップロード要求処理を示すフローチャートである。適宜図１を参照して説明する。構成管理処理部１２１は、クライアント装置２００からのアップロード要求があると、配布管理テーブル１２６（図４参照）を参照して、クライアント名とファイル名とに基づいて、クライアント装置２００に配布したマスタソースの版番を取得する（ステップＳ８０１）。構成管理処理部１２１は、ステップＳ８０１でクライアント名とファイル名とに基づく版番を取得できたか否かにより、エントリがあるか否かを判定する（ステップＳ８０２）。エントリがあれば（ステップＳ８０２，Ｙｅｓ）、ステップＳ８０３に進み、エントリがなければ（ステップＳ８０２，Ｎｏ），アップロード要求したファイル名について再ダウンロードの必要性があることを要求元に通知し（ステップＳ８２１）、処理を終了する。
【００３８】
構成管理処理部１２１が、ステップＳ８０２でエントリがあるか否かを判定するのは、ダウンロードされていないソースファイルを不正にアップロードすることを防止するためである。また、一度、変更対象となるソースファイルをダウンロードしたあとに、異なるノードを修正したソースファイルを、二重にアップロードする場合の不具合を防止するためである。詳細な説明は後記する。
【００３９】
構成管理処理部１２１は、ステップＳ８０１で取得した版番のマスタソースをＨＤＤ１３０（ディスク）から取得する（ステップＳ８０３）。そして、構成管理処理部１２１は、アップロード要求に含まれる変更済みのソース（ソースファイル）とステップＳ８０３で取得したマスタソースと比較し変更内容を抽出する（ステップＳ８０４）。具体的には、二つのファイルを比較処理すると、抽出コードが特定されその抽出コードの変更部位のノードを特定するとよい。
【００４０】
本実施形態では、クライアント装置２００側には作業者が変更した変更履歴を取らずに、自由に変更できるようにしている。すなわち、管理サーバ装置１００が、ダウンロードしたソースファイルと、アップロードしたソースファイルとを比較することにより、変更内容の部位を抽出していることがひとつの特徴となっている。
【００４１】
構成管理処理部１２１は、競合検出処理部１２２を呼び出し（ステップＳ８０５）、競合があるか否かを判定する（ステップＳ８０６）。構成管理処理部１２１は、競合があれば（ステップＳ８０６，Ｙｅｓ）、要求元にアップロードの失敗を通知し（ステップＳ８２２）、処理を終了し、競合がなければ（ステップＳ８０６，Ｎｏ）、ステップＳ８０７に進む。
【００４２】
ステップＳ８０７において、構成管理処理部１２１は、マスタソースの最新版をＨＤＤ１３０（ディスク）から取得し（ステップＳ８０７）、マスタソースに変更内容を統合し（ステップＳ８０８）、統合したマスタソースをディスクに格納する（ステップＳ８０９）。そして、構成管理処理部１２１は、変更情報を変更管理テーブル１２７（図５参照）に記録し（ステップＳ８１０）、要求元にアップロードの成功を通知し（ステップＳ８１１）、配布管理テーブル１２６（図４参照）の要求元のクライアントのエントリを消去し（ステップＳ８１２）、一連の処理を終了する。なお、ステップＳ８１２で、エントリを消去するのではなく、配布履歴を残すため、無効化処理としてもよい。
【００４３】
図９は、競合検出処理部の競合検出処理を示すフローチャートである。図８におけるステップＳ８０５の呼び出し後の処理について説明する。競合検出処理部１２２は、変更管理テーブル１２７（図５参照）を参照し、配布した版番より新しい履歴の変更部位を取得し（ステップＳ９０１）、変更部位があるか否かを判定する（ステップＳ９０２）。競合検出処理部１２２は、変更部位があれば（ステップＳ９０２，Ｙｅｓ）、ステップＳ９０３に進み、変更部位がなければ（ステップＳ９０２，Ｎｏ）、競合なしと判定し（ステップＳ９０８）、構成管理処理部１２１の処理（図８参照）に戻る。
【００４４】
ステップＳ９０３において、競合検出処理部１２２は、ステップＳ８０４で抽出した変更内容について、変更部位に含まれているかを検索し（ステップＳ９０３）、含まれている場合（ステップＳ９０４，Ｙｅｓ）、競合ありと判定し（ステップＳ９０７）、構成管理処理部１２１の処理（図８参照）に戻る。含まれていない場合（ステップＳ９０４，Ｎｏ）、ステップＳ９０５に進む。
【００４５】
ステップＳ９０５において、競合検出処理部１２２は、それぞれの変更部位について、アップロード要求に添付されてきた実行ノードテーブル２２７に含まれているか検索し（ステップＳ９０６）、含まれている場合（ステップＳ９０６，Ｙｅｓ）、競合ありと判定し（ステップＳ９０７）、構成管理処理部１２１の処理（図８参照）に戻る。一方、含まれていない場合（ステップＳ９０６，Ｎｏ）、競合なしと判定し（ステップＳ９０８）、構成管理処理部１２１の処理（図８参照）に戻る。
【００４６】
図８に戻り、ステップＳ８０２でエントリを判定している理由、すなわち、エントリ判定しない場合の二重アップロードの場合の不整合について説明する。具体的には、図３で示した例で説明すると、クライアントＡが版番１のソースファイルに対しノードＮ３を変更したものをアップロードし、さらに、クライアントＡがさらに版番１のソースファイルに対しノードＮ７を変更したものをアップロードする場合を考える。
【００４７】
クライアントＡが版番１のソースファイルに対しノードＮ３を変更後アップロードすると、構成管理処理部１２１は、アップロード要求された変更部位が版番１のマスタソースと比較してノードＮ３と特定される。そして、マスタソースにはノードＮ３の変更が統合されて版番２になる。さらに、クライアントＡが版番１のソースファイルに対しノードＮ７を変更しアップロードすると、構成管理処理部１２１は、アップロード要求された変更部位のノードが版番１のマスタソースと比較してノードＮ７と特定されるが、マスタソースの最新版は版番２であるため、版番１からの変更部位がノードＮ３である。このため、実行ノードテーブル２２７に、ノードＮ１，Ｎ２，Ｎ３，Ｎ５，Ｎ７，Ｎ８があり、ノードＮ３が競合するためアップロードが成功しないと判定され、版番の不整合による不具合が生じる。
【００４８】
これに対し、クライアントＡは、一度アップロードすると、最新版である版番２をダウンロードしてから、ノードＮ７を変更したものをアップロードすると、版番の不整合による不具合は生じない。
【００４９】
図１０は、実行ノード記録処理部によるサンプルプログラムのノード番号の採番を示す図である。配布管理テーブル１２６（図４参照）のファイル名「ｓｏｕｒｃｅ１．ｃ」のソースファイルの例である。図３に示した例と同様である。実行ノード記録処理部２２２は、実行ノードを記録するために、始点、終点、処理ボックス、および判定ボックスごとにノード番号を採番する。図１０に示す例では、始点をノードＮ１、判定ボックスをノードＮ２、処理ボックスをノードＮ３，Ｎ４、判定ボックスをノードＮ５、処理ボックスをノードＮ６，Ｎ７、および終点をノードＮ８としている。
【００５０】
図１１は、実行ノード記録処理部によるサンプルプログラムの実行ノード記録例を示す図であり、（ａ）は実行ノードテーブルの例であり、（ｂ）は複数のソースプログラムを同時にテストした場合の実行ノードテーブルの例である。ここでは、図１０に示したソースファイルをクライアント装置２００においてノードＮ３を変更し、変更したノードの動作を確認するテストをする場合について、実行ノード記録処理部２２２の記録例を説明する。
【００５１】
図１１（ａ）に示す実行ノードテーブル２２７には、変更したノードＮ３を含む経路情報が記録されており、ノードＮ１，Ｎ２，Ｎ３，Ｎ５，Ｎ６，Ｎ８と、ノードＮ１，Ｎ２，Ｎ３，Ｎ５，Ｎ７，Ｎ８が記録される。なお、図１０に示すソースファイルの場合、ノードＮ５で分岐があるので、２つの経路情報が記録される。
【００５２】
図１１（ｂ）は、ファイル名「ｓｏｕｒｃｅ１．ｃ」のソースファイルに関連あるファイル名「ｓｏｕｒｃｅ２．ｃ」も同時にダウンロードざれ、テスト実行された場合である。図１１（ｂ）に示す実行ノードテーブル２２７には、変更したノードＮ３を含む経路情報が記録されており、ノードＮ１，Ｎ２，Ｎ３，Ｎ５，Ｎ６，Ｎ８と、ノードＮ１，Ｎ２，Ｎ３，Ｎ５，Ｎ７，Ｎ８が記録されるとともに、ノードＮ１０，Ｎ１１，Ｎ１２が記録される。なお、ファイル名「ｓｏｕｒｃｅ１．ｃ」のソースファイルの場合、ノードＮ５で分岐があるので、２つの経路情報が記録される。
【００５３】
次に、各実施例について説明する。
前提条件として、図１０に示したファイル名「ｓｏｕｒｃｅ１．ｃ」のソースファイルは、マスタソースとして管理サーバ装置１００に格納済みであり、変更管理テーブル１２７には、版番１として登録されている。クライアントＡ、クライアントＢ、クライアントＣがソースファイルをダウンロードし、ソースファイルの変更をし、アップロードするが、アップロードが成功する例、アップロードが失敗する例について、複数の実施例（実施例１〜実施例１０）について、詳細に説明する。
【００５４】
（実施例１）
図１２は、実施例１の変更元が最新版のため既存ノード変更のアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態、（ｅ）はアップロード後の配布管理テーブルの状態を示す。図１３は、実施例１において、（ａ）は版番１に基づいたクライアントＡによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番２のマスタの状態を示す図である。なお、以下の実施例の説明において、変更のあったノードを明確にするため、図面の該当部分を網掛け表示することにより、明示しています。
【００５５】
実施例１では、クライアントＡが版番１のノードＮ３を変更してアップロードする例を示す。図１２（ａ）に示すように、クライアントＡ、クライアントＢ、クライアントＣがダウンロード要求して、版番１のファイル名「ｓｏｕｒｃｅ１．ｃ」のソースファイルをダウンロードしている。図１２（ｂ）に示すように、版番１には変更部位がない。図１２（ｃ）のクライアントＡの実行ノードテーブル２２７には、変更したノードＮ３を含む経路情報が記録されている（図１３（ａ）参照）。
【００５６】
クライアントＡがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図１２（ａ））を参照し、クライアントＡに配布したソースファイルの版番１を取得し、競合検出処理部１２２は、変更管理テーブル１２７（図１２（ｂ））を参照し、配布した版番より新しい履歴がないため、変更部位がないことを確認し、競合なしと判定する。マスタソースの最新版と同じ版番を基に変更した場合は、競合する変更が存在しないため、アップロードが成功する。図１２（ｄ）に示すように、変更管理テーブル１２７には、変更部位がノードＮ３として版番２が登録される。登録されたアップロード後のマスタソースの状態は、図１３（ｂ）に示す。クライアントＡは、引き続きソースファイルを変更するため、また、今後の変更に備えてダウンロード要求をすると、配布管理テーブル１２６は、図１２（ｅ）に示すようにクライアントＡについて版番２を登録する。
【００５７】
（実施例２）
図１４は、実施例２の変更管理テーブルの変更部位と同じ既存ノード変更でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。図１５は、実施例２において、（ａ）はアップロード前の版番２のマスタの状態を示す図であり、（ｂ）は版番１に基づいたクライアントＢによる変更と実行ノードを説明する図である。
【００５８】
実施例２では、実施例１を行った後のクライアントＢが版番１のノードＮ３を変更してアップロードする例を示す。図１４（ａ）に示すように、クライアントＡについては版番２をダウンロードしているが、クライアントＢ、クライアントＣは、版番１を既にダウンロードしている。図１４（ｂ）に示すように、版番２には変更部位としてノードＮ３がある（図１５（ａ）参照）。図１４（ｃ）のクライアントＢの実行ノードテーブル２２７には、変更したノードＮ３を含む経路情報が記録されている（図１５（ｂ）参照）。
【００５９】
クライアントＢがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図１４（ａ））を参照し、クライアントＢに配布したソースファイルの版番１を取得し、競合検出処理部１２２は、変更管理テーブル１２７（図１４（ｂ））を参照し、配布した版番より新しい履歴（版番２）があるため、変更部位としてノードＮ３を取得し、クライアントＢの変更内容であるノードＮ３が変更部位に含まれるため、競合ありと判定する。すなわち、マスタソースの変更履歴と同じ部位を変更した場合は、アップロードに失敗する。アップロードに失敗したため、クライアントＢのアップロード要求による変更内容は統合されず、マスタソースの状態は図１５(ａ)のままで変化しない。すなわち、図１４（ｄ）に示すように変更管理テーブル１２７には、版番２が登録されたままで変化しない。
【００６０】
（実施例３）
図１６は、実施例３の変更管理テーブルの変更部位と同じ既存ノード削除でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。図１７は、実施例３において、（ａ）はアップロード前の版番２のマスタの状態を示す図であり、（ｂ）は版番１に基づいたクライアントＢによる変更と実行ノードを説明する図である。
【００６１】
実施例３では、実施例１を行った後のクライアントＢが版番１のノードＮ３を削除してアップロードする例を示す。図１６（ａ）に示すように、クライアントＡは版番２をダウンロードしているが、クライアントＢ、クライアントＣは、版番１を既にダウンロードしている。図１６（ｂ）に示すように、版番２には変更部位としてノードＮ３がある（図１７（ａ）参照）。図１６（ｃ）のクライアントＢの実行ノードテーブル２２７には、ノードＮ３を削除したことを確認するための経路情報が記録されている（図１７（ｂ）参照）。
【００６２】
クライアントＢがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図１６（ａ））を参照し、クライアントＢに配布したソースファイルの版番１を取得し、競合検出処理部１２２は、変更管理テーブル１２７（図１６（ｂ））を参照し、配布した版番より新しい履歴（版番２）があるため、変更部位としてノードＮ３を取得し、クライアントＢの変更内容であるノードＮ３が変更部位に含まれるため、競合ありと判定する。すなわち、マスタソースの変更履歴と同じ部位を削除した場合は、アップロードに失敗する。アップロードに失敗したため、クライアントＢのアップロード要求による変更内容は統合されず、マスタソースの状態は図１７(ａ)のままで変化しない。すなわち、図１６（ｄ）に示すように変更管理テーブル１２７には、版番２が登録されたままで変化しない。
【００６３】
（実施例４）
図１８は、実施例４の変更管理テーブルの変更部位と競合しない既存ノード変更でアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態、（ｅ）はアップロード後の配布管理テーブルの状態を示す。図１９は、実施例４において、（ａ）は版番１に基づいたクライアントＢによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番３のマスタの状態を示す図である。
【００６４】
実施例４では、実施例１を行った後のクライアントＢが版番１のノードＮ４を変更してアップロードする例を示す。図１８（ａ）に示すように、クライアントＡについては版番２がダウンロードされているが、クライアントＢ、クライアントＣは、版番１を既にダウンロードしている。図１８（ｂ）に示すように、版番２には変更部位としてノードＮ３がある。図１８（ｃ）のクライアントＢの実行ノードテーブル２２７には、変更したノードＮ４を含む経路情報が記録されている（図１９（ａ）参照）。
【００６５】
クライアントＢがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図１８（ａ））を参照し、クライアントＢに配布したソースファイルの版番１を取得し、競合検出処理部１２２は、変更管理テーブル１２７（図１８（ｂ））を参照し、配布した版番より新しい履歴（版番２）があるため、変更部位としてノードＮ３を取得し、クライアントＢの変更内容であるノードＮ４は、変更部位に含まれていないと判定する。さらに、競合検出処理部１２２は、実行ノードテーブル２２７（図１８（ｃ））を参照して、変更部位Ｎ３が実行ノードに存在しないため、競合なしと判定する。すなわち、マスタソースに変更があっても、テスト実行で通らない部分の場合は、アップロードに成功する。アップロードに成功したため、図１８（ｄ）に示すように変更管理テーブル１２７には、版番３が登録される。登録されたアップロード後のマスタソースの状態は、図１９（ｂ）に示す。クライアントＢは、引き続きソースファイルを変更するため、また、今後の変更に備えてダウンロード要求をすると、配布管理テーブル１２６は、図１８（ｅ）に示すようにクライアントＢについて版番３を登録する。
【００６６】
（実施例５）
図２０は、実施例５の変更管理テーブルの変更部位と同じ既存ノード変更でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。図２１は、実施例５において、（ａ）はアップロード前の版番３のマスタの状態を示す図であり、（ｂ）は版番１に基づいたクライアントＣによる変更と実行ノードを説明する図である。
【００６７】
実施例５では、実施例４を行った後のクライアントＣが版番１のノードＮ６を変更してアップロードする例を示す。図２０（ａ）に示すように、クライアントＡは版番２をダウンロードし、クライアントＢは版番３をダウンロードし、クライアントＣは版番１を既にダウンロードしている。図２０（ｂ）に示すように、版番２には変更部位としてノードＮ３があり、版番３には変更部位としてノードＮ４がある（図２１（ａ）参照）。図２０（ｃ）のクライアントＣの実行ノードテーブル２２７には、変更したノードＮ６を含む経路情報が記録されている（図２１（ｂ）参照）。
【００６８】
クライアントＣがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図２０（ａ））を参照し、クライアントＣに配布したソースファイルの版番１を取得し、競合検出処理部１２２は、変更管理テーブル１２７（図２０（ｂ））を参照し、配布した版番より新しい履歴（版番２、版番３）があるため、変更部位としてノードＮ３，Ｎ４を取得し、クライアントＣの変更内容であるノードＮ６は、変更部位に含まれていないと判定する。次に、競合検出処理部１２２は、実行ノードテーブル２２７（図２０（ｃ））を参照して、変更部位Ｎ３，Ｎ４が実行ノードに存在するため、競合ありと判定し、アップロードに失敗する。テスト実行で通った部分にマスタソースの変更がある場合は、アップロードに失敗する。アップロードに失敗したため、クライアントＣのアップロード要求による変更内容は統合されず、マスタソースの状態は図２１(ａ)のままで変化しない。すなわち、図２０（ｄ）に示すように変更管理テーブル１２７は、版番３のままで変化しない。
【００６９】
（実施例６）
図２２は、実施例６のマスタの再取得により変更管理テーブルの変更部位と競合しない既存ノード変更でアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態、（ｅ）はアップロード後の配布管理テーブルの状態を示す。図２３は、実施例６において、（ａ）は版番３に基づいたクライアントＣによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番４のマスタの状態を示す図である。
【００７０】
実施例６では、実施例５でアップロードに失敗したクライアントＣが、再度ソースファイルのダウンロード要求をし、最新版である版番３のソースファイルを取得し、ノードＮ６を変更してアップロードする例を示す。図２２（ａ）に示すように、クライアントＣは版番３をダウンロードしている。図２２（ｂ）に示すように、版番２には変更部位としてノードＮ３があり、版番３には変更部位としてノードＮ４がある。図２２（ｃ）のクライアントＣの実行ノードテーブル２２７には、変更したノードＮ６を含む経路情報が記録されている（図２３（ａ）参照）。
【００７１】
クライアントＣがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図２２（ａ））を参照し、クライアントＣに配布したソースファイルの版番３を取得し、競合検出処理部１２２は、変更管理テーブル１２７（図２２（ｂ））を参照し、配布した版番より新しい履歴がないため、変更部位はなしを取得し、変更部位がないため、競合なしと判定する。すなわち、マスタソースの最新版と同じ版番を基に変更した場合、競合する変更が存在しないため、アップロードに成功する。アップロードに成功したため、図２２（ｄ）に示すように変更管理テーブル１２７には、版番４が登録される。登録されたアップロード後のマスタソースの状態は、図２３（ｂ）に示す。クライアントＣは、引き続きソースファイルを変更するため、また、今後の変更に備えてダウンロード要求をすると、配布管理テーブル１２６は、図２２（ｅ）に示すようにクライアントＣについて版番４を登録する。
【００７２】
（実施例７）
図２４は、実施例７の変更管理テーブルの変更部位と競合する新規ノード追加でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。図２５は、実施例７において、（ａ）はアップロード前の版番４のマスタの状態を示す図であり、（ｂ）は版番２に基づいたクライアントＡによる変更と実行ノードを説明する図である。
【００７３】
実施例７では、実施例６を行った後にクライアントＡが版番２のノードＮ１とノードＮ２の間にノードＮ９を追加してアップロードする例を示す。図２４（ａ）に示すように、クライアントＡは版番２をダウンロードしている。図２４（ｂ）に示すように、版番２には変更部位としてノードＮ３があり、版番３には変更部位としてノードＮ４があり、版番４には、変更部位としてノードＮ６がある（図２５（ａ）参照）。図２４（ｃ）のクライアントＡの実行ノードテーブル２２７には、変更したノードＮ９を含む経路情報が記録されている（図２５（ｂ）参照）。
【００７４】
クライアントＡがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図２４（ａ））を参照し、クライアントＡに配布したソースファイルの版番２を取得し、クライアントＡの変更内容として、ノードＮ１，Ｎ２，Ｎ９を取得する。
【００７５】
なお、構成管理処理部１２１は、追加ノードはＮ９であるがノード間のつながりも変更されているので、変更内容としてノードＮ１，Ｎ２も取得している。すなわち、ノードを追加した場合は、追加したノードの前後のノードも変更内容として抽出することで、追加位置と影響範囲が管理される。
【００７６】
競合検出処理部１２２は、変更管理テーブル１２７（図２４（ｂ））を参照し、配布した版番より新しい履歴（版番３、版番４）があるため、変更部位としてノードＮ４，Ｎ６を取得し、クライアントＡの変更内容は、変更部位に含まれていないと判定する。次に、競合検出処理部１２２は、実行ノードテーブル２２７（図２４（ｃ））を参照して、変更部位Ｎ４，Ｎ６が実行ノードに存在するため、競合ありと判定し、アップロードに失敗する。アップロードに失敗したため、クライアントＡのアップロード要求による変更内容は統合されず、マスタソースの状態は図２５(ａ)のままで変化しない。すなわち、図２４（ｄ）に示すように変更管理テーブル１２７は、版番４のままで変化しない。
【００７７】
（実施例８）
図２６は、実施例８のマスタの再取得により新規ノード追加でアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態を示す。図２７は、実施例８において、（ａ）は版番４に基づいたクライアントＡによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番５のマスタの状態を示す図である。
【００７８】
実施例８では、実施例７でアップロードに失敗したクライアントＡが、再度ソースファイルのダウンロード要求をし、最新版である版番４のソースファイルを取得し、ノードＮ１とノードＮ２間にノードＮ９を追加してアップロードする例を示す。図２６（ａ）に示すように、クライアントＡは版番４をダウンロードしている。図２６（ｂ）に示すように、版番２には変更部位としてノードＮ３があり、版番３には変更部位としてノードＮ４があり、版番４には、変更部位としてノードＮ６がある。図２６（ｃ）のクライアントＡの実行ノードテーブル２２７には、追加したノードＮ９を含む経路情報が記録されている（図２７（ａ）参照）。
【００７９】
クライアントＡがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図２６（ａ））を参照し、クライアントＡに配布したソースファイルの版番４を取得し、クライアントＡの変更内容として、ノードＮ１，Ｎ２，Ｎ９を取得する。競合検出処理部１２２は、変更管理テーブル１２７（図２６（ｂ））を参照し、配布した版番より新しい履歴がないため、変更部位はなしを取得し、変更部位がないため、競合なしと判定する。すなわち、マスタソースの最新版と同じ版番を基に変更した場合、競合する変更が存在しないため、アップロードに成功する。アップロードに成功したため、図２６（ｄ）に示すように変更管理テーブル１２７には、版番５が登録される。登録されたアップロード後のマスタソースの状態は、図２７（ｂ）に示す。クライアントＡは、引き続きソースファイルを変更するため、また、今後の変更に備えてダウンロード要求をすると、配布管理テーブル１２６は、クライアントＡについて版番５を登録する。
【００８０】
（実施例９）
図２８は、実施例９の変更管理テーブルの変更部位と競合する既存ノード削除でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロードの失敗後の変更管理テーブルの状態を示す。図２９は、実施例９において、（ａ）はアップロード前の版番５のマスタの状態を示す図であり、（ｂ）は版番３に基づいたクライアントＢによる変更と実行ノードを説明する図である。
【００８１】
実施例９では、実施例８を行った後にクライアントＢが版番３のノードＮ７を削除してアップロードする例を示す。図２８（ａ）に示すように、クライアントＢは版番３をダウンロードしている。図２８（ｂ）に示すように、版番２には変更部位としてノードＮ３があり、版番３には変更部位としてノードＮ４があり、版番４には変更部位としてノードＮ６があり、版番５には変更部位としてノードＮ１，Ｎ２，Ｎ９がある（図２９（ａ）参照）。図２８（ｃ）のクライアントＢの実行ノードテーブル２２７には、削除したノードＮ７を含まない経路情報が記録されている（図２９（ｂ）参照）。
【００８２】
クライアントＢがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図２８（ａ））を参照し、クライアントＢに配布したソースファイルの版番３を取得し、競合検出処理部１２２は、変更管理テーブル１２７（図２８（ｂ））を参照し、配布した版番より新しい履歴（版番４、版番５）があるため、変更部位としてノードＮ１，Ｎ２，Ｎ６，Ｎ９を取得し、クライアントＢの削除ノードＮ７は、変更部位に含まれていないと判定する。次に、競合検出処理部１２２は、実行ノードテーブル２２７（図２８（ｃ））を参照して、変更部位Ｎ１，Ｎ２，Ｎ６が実行ノードに存在するため、競合ありと判定し、アップロードに失敗する。テスト実行で通った部分にマスタソースの変更部位がある場合は、アップロードに失敗する。アップロードに失敗したため、クライアントＢのアップロード要求による変更内容は統合されず、マスタソースの状態は図２９(ａ)のままで変化しない。すなわち、図２８（ｄ）に示すように変更管理テーブル１２７は、版番５のままで変化しない。
【００８３】
（実施例１０）
図３０は、実施例１０のマスタの再取得により既存ノード削除でアップロードに成功するケースにおける各テーブルの状態を示す図であり、（ａ）はアップロード前の配布管理テーブルの状態、（ｂ）はアップロード前の変更管理テーブルの状態、（ｃ）は実行ノードテーブルの状態、（ｄ）はアップロード後の変更管理テーブルの状態を示す。図３１は、実施例１０において、（ａ）は版番５に基づいたクライアントＢによる変更と実行ノードを説明する図であり、（ｂ）はアップロード後の版番６のマスタの状態を示す図である。
【００８４】
実施例１０では、実施例９でアップロードに失敗したクライアントＢが、再度ソースファイルのダウンロード要求をし、最新版である版番５のソースファイルを取得し、ノードＮ７を削除してアップロードする例を示す。図３０（ａ）に示すように、クライアントＢは版番５をダウンロードしている。図３０（ｂ）に示すように、版番２には変更部位としてノードＮ３があり、版番３には変更部位としてノードＮ４があり、版番４には、変更部位としてノードＮ６があり、版番５には変更部位としてノードＮ１，Ｎ２，Ｎ６がある。図３０（ｃ）のクライアントＢの実行ノードテーブル２２７には、削除したノードＮ７を含まない経路情報が記録されている（図３１（ａ）参照）。
【００８５】
クライアントＢがアップロード要求をすると、構成管理処理部１２１は、配布管理テーブル１２６（図３０（ａ））を参照し、クライアントＢに配布したソースファイルの版番５を取得する。競合検出処理部１２２は、変更管理テーブル１２７（図３０（ｂ））を参照し、配布した版番より新しい履歴がないため、変更部位はなしを取得し、変更部位がないため、競合なしと判定する。すなわち、マスタソースの最新版と同じ版番を基に変更した場合、競合する変更が存在しないため、アップロードに成功する。アップロードに成功したため、図３０（ｄ）に示すように変更管理テーブル１２７には、版番６が登録される。登録されたアップロード後のマスタソースの状態は、図３１（ｂ）に示す。
【００８６】
以上の実施例では、クライアント装置２００がひとつのソースファイルをダウンロードし、アップロードする例について説明した。しかし、これに限定される必要はなく複数のソースファイルの場合にも本実施形態は適用することができる。
【００８７】
改善箇所や新規機能を実現するために、複数のソースファイルを同時に変更する必要がある。関連あるソースファイルを１つずつアップロードすると、ソースファイルのどれかで競合が発生してアップロードに失敗した場合、一部のソースファイルだけアップロードされてしまい、全体として不完全な状態が発生する可能性がある。具体的には、「ｓｏｕｒｃｅ１．ｃ」および「ｓｏｕｒｃｅ２．ｃ」を同時に変更し、相互に呼び出し関係があるとする。「ｓｏｕｒｃｅ１．ｃ」のアップロードに成功したあと、「ｓｏｕｒｃｅ２．ｃ」のアップロードに失敗すると、管理サーバ装置１００では、「ｓｏｕｒｃｅ１．ｃ」のマスタソースしか更新されず、不整合によりコンパイラエラーなどが発生する場合がある。これに対処するため、図３２を参照して複数のソースファイルのアップロード要求処理をする場合について説明する。
【００８８】
図３２は、構成管理処理部のクライアントからの他のアップロード要求処理を示すフローチャートである。図３２のフローチャートは図８のフローチャートに基づいており、追加ステップは、複数のソースファイルについて繰り返すペアのループ端であるステップＳ８２１およびステップＳ８２２、同様にペアのループ端であるステップＳ８３１およびステップＳ８３２である。変更ステップは、アップロードされたいずれかのソースファイルに競合があるか否かを判定するステップＳ８０６Ａである。他のステップは、図８と同様であるので説明を省略する。
【００８９】
図３２によれば、アップロード要求されたソースファイルのすべてについて、ステップＳ８２１からステップＳ８２２のループ処理で、各変更済みのソースファイルとマスタソースのファイルとに競合があるか否かを判定し、いずれかのファイルに競合がある場合（ステップＳ８０６Ａ，Ｙｅｓ）、ステップＳ８２２に進む。一方、すべてのファイルに競合がない場合（ステップＳ８０６Ａ，Ｎｏ）、ステップＳ８３１からステップＳ８３２のループ処理で、マスタソースに変更内容を統合する。
【００９０】
実施例１〜１０においては、テスト実行処理部２２１（図１参照）は、変更対象となるソースファイルをテストした例について示したが、変更したファイルだけでなく、テストの前提となる経路（呼び出し元など）に競合がないことを確認することで、マスタソースに変更ファイルを統合する際の品質向上を図ることができる。
【００９１】
図３３は、（ａ）は複数のソースファイルが親子の関係にある場合の実行ノードテーブルを示す図であり、（ｂ）は呼び出し元から変更対象のソースファイルの実行ノードを説明する図である。図３３（ｂ）に示すように、テスト実行処理部２２１は、例えば、呼び出し元（ｓｏｕｒｃｅ２．ｃ）のノードＮ１３から呼び出し先（ｓｏｕｒｃｅ３．ｃ）を実行する。クライアントＡが「ｓｏｕｒｃｅ３．ｃ」を変更する場合、その呼び出し元である「ｓｏｕｒｃｅ２．ｃ」も管理サーバ１００から配布を受けてテスト実行する。図３３（ａ）に示すクライアントＡの実行ノードテーブル２２７には、「ｓｏｕｒｃｅ３．ｃ」だけでなく、「ｓｏｕｒｃｅ２．ｃ」のテスト実行ノードも記録され、競合検出の範囲を拡大することができる。
【００９２】
本実施形態では、実行ノード記録処理部２２２（図１参照）において、実行ノードを記録している。ノードは、図１０では、処理ブロック、判定ブロックなどとして説明しているが、ステップごとに記録してもよい。
【００９３】
ステップとは、コンピュータの処理段階を表す単位のことであり、処理の大きさを「何ステップ」であると表現することが一般的である。なお、ステップ数はソースプログラムの命令後の数と対応するが、必ずしもプログラミング言語の単語数とは一致せず、言語によっては複数の単語で1ステップの処理が定義されている場合もある。
【００９４】
また、本実施形態では、ノードをモジュールやライブラリと設定することで、複数のモジュールやライブラリから構成されるシステムを変更する際の競合を検出することができる。
【００９５】
本実施形態によれば、管理サーバ装置１００からダウンロードしたソースファイルについて、クライアント装置２００のテスト実行処理部２２１が作業者が変更したノードを含むソースファイルをテストをする際に、実行ノード記録処理部２２２がテストで実行したノードの経路情報（変更に伴う影響範囲）を記録し、アップロード処理部２２５がノードの経路情報を添付して変更したソースファイルのアップロード要求を管理サーバ装置１００にする。管理サーバ装置１００は、競合検出処理部１２２が該変更に伴う影響範囲を他の作業者が変更加えていなかった場合に競合がないと判定し、構成管理処理部１２１がマスタソースに変更したソースファイルの統合をする。複数の作業者が並行開発している複数のノードから構成されるソースファイルを効率よく管理することができる。
【符号の説明】
【００９６】
１００    管理サーバ装置（管理サーバ）
１１０，２１０    ＣＰＵ
１２０，２２０    メモリ
１２１    構成管理処理部
１２２    競合検出処理部
１２３，２２３    ＯＳ
１２６    配布管理テーブル（配布管理情報）
１２７    変更管理テーブル（変更管理情報）
１３０，２３０    ＨＤＤ（ディスク）
１４０，２４０    ＮＩＣ
２００    クライアント装置（クライアント）
２２１    テスト実行処理部
２２２    実行ノード記録処理部
２２４    ダウンロード処理部
２２５    アップロード処理部
２２６    編集部
２２７    実行ノードテーブル（実行ノード情報）
３００    ネットワーク
【図１】
2012230636.tif 000003
【図２】
2012230636.tif 000004
【図３】
2012230636.tif 000005
【図４】
2012230636.tif 000006
【図５】
2012230636.tif 000007
【図６】
2012230636.tif 000008
【図７】
2012230636.tif 000009
【図８】
2012230636.tif 000010
【図９】
2012230636.tif 000011
【図１０】
2012230636.tif 000012
【図１１】
2012230636.tif 000013
【図１２】
2012230636.tif 000014
【図１３】
2012230636.tif 000015
【図１４】
2012230636.tif 000016
【図１５】
2012230636.tif 000017
【図１６】
2012230636.tif 000018
【図１７】
2012230636.tif 000019
【図１８】
2012230636.tif 000020
【図１９】
2012230636.tif 000021
【図２０】
2012230636.tif 000022
【図２１】
2012230636.tif 000023
【図２２】
2012230636.tif 000024
【図２３】
2012230636.tif 000025
【図２４】
2012230636.tif 000026
【図２５】
2012230636.tif 000027
【図２６】
2012230636.tif 000028
【図２７】
2012230636.tif 000029
【図２８】
2012230636.tif 000030
【図２９】
2012230636.tif 000031
【図３０】
2012230636.tif 000032
【図３１】
2012230636.tif 000033
【図３２】
2012230636.tif 000034
【図３３】
2012230636.tif 000035