パッチ管理装置、パッチ管理方法及びパッチ管理プログラム
【課題】ネットワークを介して互いに通信可能な複数のクライアントの間で、パッチ間の競合及び個々のクライアントにおけるパッチのマージ作業を回避しつつ、パッチを当てることのできるパッチ管理方法を提供すること。
【解決手段】パッチ管理装置３０は、ネットワークを介して互いに通信可能な複数のクライアント６０ｐ〜６０ｔのそれぞれのリポジトリ４０に対するパッチを管理する。パッチ管理装置３０は、共通パッチ生成部１３及びパッチ演算部１４を備える。共通パッチ生成部１３は、クライアント６０ｐ〜６０ｔそれぞれのリポジトリ４０のいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する。パッチ演算部１４は、共通パッチをリポジトリ４０に格納されたデータにマージする。
【解決手段】パッチ管理装置３０は、ネットワークを介して互いに通信可能な複数のクライアント６０ｐ〜６０ｔのそれぞれのリポジトリ４０に対するパッチを管理する。パッチ管理装置３０は、共通パッチ生成部１３及びパッチ演算部１４を備える。共通パッチ生成部１３は、クライアント６０ｐ〜６０ｔそれぞれのリポジトリ４０のいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する。パッチ演算部１４は、共通パッチをリポジトリ４０に格納されたデータにマージする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はパッチ管理装置、パッチ管理方法及びパッチ管理プログラムに関し、特にネットワーク間で分散管理されたファイル集合について、競合を起こすことなくパッチをファイル集合へ反映させることを可能にするパッチ管理装置、パッチ管理方法及びパッチ管理プログラムに関する。
【背景技術】
【０００２】
従来から、プログラムを共同開発する際に、ソースコードのコピーを開発者全員がリポジトリに設けた記憶装置に保持し、ファイルに対して行われた変更点のみを開発者間でやりとりしつつ開発を進める方法が利用されている。共同開発へ参加する開発者は、始めにソースコードのコピーを手元のリポジトリへコピーしておいて、変更を行った際にはパッチと呼ばれる変更点のみを他の開発者へ配布することで、ネットワークを介した分散環境においても、一つのプログラムを効率良く共同開発することができる。
【０００３】
特許文献１に開示されたパッチ管理装置においては、パッチをファイルシステムへの変更点として抽出し、パッチ適用対象のファイルシステムへ上書きしていた。具体的には、ファイルシステムの変更前と変更後それぞれの状態を持つ仮想マシン（バーチャルマシン）を作成し、仮想マシン中のファイルそれぞれについて、ファイルの追加や削除、ファイルのタイムスタンプ、サイズ及びハッシュ値の変化を検査することによって変更されたファイル集合を抽出し、このファイル集合をパッチとしてパッチ適用対象のファイルシステムへ上書きしていた。
【０００４】
特許文献２に開示されたパッチ管理装置においては、ソースコードを管理する中央リポジトリ（ソースコード管理サーバ）によって、クライアントから受信したソースコードの変更点をソースコードの構文解析結果である構文ツリーへのパッチとして管理し、クライアントは必要に応じてソースコード管理サーバ上の更新されたパッチを手元のリポジトリへ適用することでソースコード管理を行っていた。
【０００５】
【特許文献１】特開２００３−２９６１３２号公報
【特許文献２】特開２００５−３４６６６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
以下の分析は、本発明者によってなされたものである。従来のパッチ管理装置では、パッチを他の全てのリポジトリへ反映するために、特許文献１のように変更されたファイル集合をパッチとして上書きする方法や、特許文献２のようにパッチを一元的に管理する中央リポジトリを経由する方法があった。
【０００７】
特許文献１の方法によれば、パッチを他のリポジトリへ反映する際には、パッチであるファイル集合がパッチ適用対象のリポジトリへ上書きされる。すなわち、リポジトリごとの変更点はパッチの上書きにより失われる可能性がある。したがって、リポジトリごとの変更点を残しつつ、マージ可能なパッチのみを適用することを目的としたパッチ管理には向いていない。
【０００８】
特許文献２の方法によれば、ローカルに作成したパッチを他の全リポジトリへ反映するためには、いったん中央リポジトリへすべてのパッチをコミットと呼ばれる操作で登録しておき、他の全てのリポジトリ上でこのパッチを反映させる操作を実行する必要があった。
【０００９】
このため、第１の問題点として、パッチを作成したユーザが一元的に反映操作を実行できず、他のリポジトリを備えたマシンへリモートログインするなどして反映しなければならないという問題があった。また、パッチを反映させる際には、ローカルで独自に作成したパッチと中央リポジトリから取得したパッチとが競合を起こす可能性がある。このため、第２の問題点として、各リポジトリ上でマージと呼ばれる修正処理を行う必要があった。
【００１０】
そこで、ネットワークを介して互いに通信可能な複数のクライアントの間で、パッチ間の競合及び個々のクライアントにおけるパッチのマージ作業を回避しつつ、パッチを当てることのできるパッチ管理方法を提供することが課題となる。
【課題を解決するための手段】
【００１１】
本発明の第１の視点に係るパッチ管理装置は、
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理するパッチ管理装置であって、
前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出するように構成された共通パッチ生成部と、
前記共通パッチを前記リポジトリに格納されたデータにマージするように構成されたパッチ演算部と、を備えることを特徴とする。
【００１２】
第１の展開形態のパッチ管理装置は、
前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するように構成されたパッチ抽出部を備え、
前記共通パッチ生成部は、前記マージ可能パッチを参照し、その共通部分を共通パッチとして抽出するように構成されることが好ましい。
【００１３】
第２の展開形態のパッチ管理装置は、
パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化部を備え、
前記パッチ抽出部は、前記パッチ正規化部によって分解されたパッチの積を参照し、前記マージ可能パッチを抽出するように構成されることが好ましい。
【００１４】
第３の展開形態のパッチ管理装置は、
前記リポジトリのすべてに対する操作をロックするとともに、操作のロックを解除するように構成された分散ロック部を備えることが好ましい。
【００１５】
本発明の第２の視点に係るパッチ管理方法は、
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理するパッチ管理方法であって、
（ａ）前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する共通パッチ生成工程と、
（ｂ）前記共通パッチを前記リポジトリに格納されたデータにマージするパッチ演算工程と、を含むことを特徴とする。
【００１６】
第４の展開形態のパッチ管理方法は、
（ｃ）前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するパッチ抽出工程を含み、
前記共通パッチ生成工程（ａ）において、前記マージ可能パッチの共通部分を共通パッチとして抽出することが好ましい。
【００１７】
第５の展開形態のパッチ管理方法は、
（ｄ）パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化工程を含み、
前記パッチ抽出工程（ｃ）において、前記パッチ正規化工程（ｄ）において分解されたパッチの積に基づいて前記マージ可能パッチを抽出することが好ましい。
【００１８】
第６の展開形態のパッチ管理方法は、
前記リポジトリのすべてに対する操作をロックする工程と、
そのロックを解除する工程と、をそれぞれ最初と最後に含むことが好ましい。
【００１９】
本発明の第３の視点に係るパッチ管理プログラムは、
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理する処理をコンピュータに実行させるパッチ管理プログラムであって、
（ａ）前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する共通パッチ生成処理と、
（ｂ）前記共通パッチを前記リポジトリに格納されたデータにマージするパッチ演算処理と、をコンピュータに実行させることを特徴とする。
【００２０】
第７の展開形態のパッチ管理プログラムは、
（ｃ）前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するパッチ抽出処理をコンピュータに実行させ、
前記共通パッチ生成処理（ａ）において、前記マージ可能パッチの共通部分を共通パッチとして抽出する処理をコンピュータに実行させることが好ましい。
【００２１】
第８の展開形態のパッチ管理プログラムは、
（ｄ）パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化処理をコンピュータに実行させ、
前記パッチ抽出処理（ｃ）において、前記パッチ正規化処理（ｄ）において分解されたパッチの積に基づいて前記マージ可能パッチを抽出する処理をコンピュータに実行させることが好ましい。
【００２２】
第９の展開形態のパッチ管理プログラムは、
前記リポジトリのすべてに対する操作をロックする処理と、
そのロックを解除する処理と、をそれぞれ最初と最後にコンピュータに実行させることが好ましい。
【発明の効果】
【００２３】
本発明により、ネットワークを介して互いに通信可能な複数のクライアントの間で、パッチ間の競合及び個々のクライアントにおけるパッチのマージ作業を回避しつつ、パッチを当てることのできるパッチ管理方法が提供される。すなわち、作成したパッチを他の全てのリポジトリへ反映させたい場合、他のリポジトリへパッチ反映やマージを依頼することなく、全リポジトリへマージ可能なパッチをパッチ演算に基づいて判定し、マージすることができる。
【００２４】
本発明により、例えば、異なる管理者によって個別に管理されるマシン間において設定ファイルを共有する場合において、重要な設定変更を他のマシンへ反映させる必要が生じた際に、他のマシンの管理者に手間をかけることなく、重要な設定の変更点のみを複数マシンに対して競合を起こすことなく反映させることができる。
【発明を実施するための最良の形態】
【００２５】
本発明の実施形態について図面を参照して詳細に説明する。図１は、本発明の第１の実施の形態に係るパッチ管理装置３０を備えたクライアント６０の構成を示すブロック図である。クライアント６０は、パッチ管理装置３０、リポジトリ４０、ユーザインタフェース５０を備える。
【００２６】
パッチ管理装置３０はパッチの管理を行う。リポジトリ４０はコミットされたパッチを保持する。ユーザインタフェース５０は、パッチのコミットや全リポジトリへのパッチのマージを指示し、またマージ結果をユーザへ表示する。
【００２７】
図２は、ネットワークを介して互いに通信可能な複数のクライアントの間におけるパッチ管理を説明するための図である。図２において、クライアント６０ｐは、ネットワーク７０を通じて他のクライアント６０ｑ〜６０ｔと通信可能である。すべてのクライアント６０ｐ〜６０ｔは、初期状態として、共通した同一のパッチ集合を自身のリポジトリ４０に保持する。ある１つのクライアント６０ｐが新たなパッチを作成し、他のクライアント６０ｑ〜６０ｔ上のリポジトリ４０へ反映させたい場合には、パッチ管理装置３０を通じて他のすべてのクライアント６０ｑ〜６０ｔ上のリポジトリ４０に対するマージ処理を行う。
【００２８】
パッチ管理装置３０は、パッチ再構成部１０と分散ロック部２０を備える。パッチ再構成部１０は、パッチ集合を入力とし、他の全てのリポジトリでパッチが競合を起こさないための再構成を行う。分散ロック部２０は、他の全てのリポジトリ４０のロックを行う。
【００２９】
ユーザインタフェース５０は、ユーザが作成したパッチを同じクライアント６０上のリポジトリ４０、もしくはネットワーク７０を通じて接続された他のクライアント６０上のリポジトリ４０へマージするためのインタフェースである。例えば、ユーザインタフェース５０を通じてコミットを指示すると、ユーザが作成したパッチをリポジトリ４０へコミットする。また、マージを指示すると、ネットワーク７０を通じて接続された他の全てのクライアント６０ｑ〜６０ｔのリポジトリ４０へユーザが作成したパッチをマージする。また、マージの後、マージの成功や失敗、マージ時にどのパッチが実際にマージできたか等の実行結果をユーザへ表示する。
【００３０】
リポジトリ４０は、パッチ記憶装置４１とリポジトリ操作部４２を備える。パッチ記憶装置４１は、コミットされたパッチ集合を保持するための記憶手段である。リポジトリ操作部４２はパッチ集合を入力とし、パッチ記憶装置４１へパッチを登録し、パッチ演算部１４からの要求に応じて、コミットされたパッチ集合を取り出す。
【００３１】
リポジトリ４０に対して変更を加えるパッチの種類は、「ファイルの追加（ｎｅｗ）」、「ファイルの削除（ｄｅｌｅｔｅ）」、「ファイル内容の編集（ｅｄｉｔ）」の３通りである。「ファイルの追加」パッチは、新たなファイルａをリポジトリ４０に追加する。
以下ではこれを「ｎｅｗ（ａ）」パッチと呼ぶ。「ファイルの削除」パッチはリポジトリ４０中のファイルａを削除する。以下ではこれを「ｄｅｌ（ａ）」パッチと呼ぶ。「ファイル内容の編集」パッチはリポジトリ４０中のファイルａの指定された部分へ行を追加または削除する。以下ではこれを「ｅｄｉｔ（ａ）」パッチと呼ぶ。
【００３２】
図３にｅｄｉｔ（）パッチによって行が追加または削除される例を示す。図３（ａ）によると、このｅｄｉｔ（）パッチはファイルの指定された部分へ行を追加するパッチである。ファイルにｅｄｉｔ（）パッチを適用することで、ファイルのα行目からβ行目の部分に行が追加される。図３（ｂ）によると、このｅｄｉｔ（）パッチはファイルの指定された部分から行を削除するパッチである。ファイルにｅｄｉｔ（）パッチを適用することで、ファイルのα行目からβ行目の部分が削除される。以下では、この追加または削除されるα行目からβ行目までの範囲をｈｕｎｋ（α、β）と呼ぶ。
【００３３】
パッチ集合とは、リポジトリ４０に変更を加えるパッチの順序付き集合である。図４にパッチ集合の構成を示す。図４に示されるように、パッチは属性として適用順序を持ち、パッチ集合を適用する際にはこの適用順序の順番にパッチが適用される。パッチを適用する順番は厳密に守られる必要がある。これは、パッチ集合内のパッチの順序を入れ替えた場合には、パッチの適用に失敗したり、パッチ集合がリポジトリ４０に行う変更内容が変わったりするためである。すなわち、あるファイルに２つのパッチＡ、Ｂを順に適用する操作をＡとＢの積ＡＢで表すものとすると、パッチの積の間には、交換則が成り立たない場合がある（すなわち、ＡＢ≠ＢＡ）。
【００３４】
パッチ順序の入れ替えによって、パッチの適用が失敗する例として、パッチＡが「ａｄｄ（ａ）」パッチで、パッチＢが「ｅｄｉｔ（ａ）」パッチである場合が挙げられる。この場合、Ａ、Ｂの順にパッチを適用することはできるが、Ｂ、Ａの順にパッチを適用することはできない。ファイルａがパッチＡにより追加される前に、ファイルａへ行を追加することはできないからである。
【００３５】
一方、パッチ順序の入れ替えにより変更内容が変わってしまう例として、パッチＣが「ｈｕｎｋ（２０、２１）を追加するｅｄｉｔ（ｂ）」パッチで、パッチＤが「ｈｕｎｋ（１０、１１）を追加するｅｄｉｔ（ｂ）」パッチである場合が挙げられる。Ｃ、Ｄ、の順にパッチを適用した結果と、Ｄ、Ｃの順にパッチを適用した結果は異なる。これは、以下の理由による。すなわち、Ｃ、Ｄの順にパッチを適用した場合、パッチ適用前のファイルｂの１０行目、２０行目に新たな行が挿入される。一方、Ｄ、Ｃの順にパッチを適用した場合、Ｄを適用した段階で元々のファイルｂの１１行目以降の行は１行ずつずれるため、Ｃで追加される行はもともとのファイルｂの１８行目と１９行目の間に挿入される。
【００３６】
パッチ再構成部１０は、パッチ正規化部１１と、パッチ同報部１２と、共通パッチ生成部１３と、パッチ演算部１４を備える。パッチ正規化部１１は、ユーザインタフェース５０から渡されたパッチ集合を変形し、ｎｅｗ（）、ｄｅｌ（）、および１つのｈｕｎｋを編集するｅｄｉｔパッチの積に分解する。また、パッチ集合の中から不要なパッチを削除する。これらを正規化処理と呼ぶ。
【００３７】
図５に正規化処理の一例を説明する。図５によると、正規化前のパッチＡはｈｕｎｋ（α、β）、およびｈｕｎｋ（γ、δ）を編集するｅｄｉｔパッチである。これらのパッチを正規化すると、ｈｕｎｋ（α、β）を編集するｅｄｉｔパッチＡ１と、ｈｕｎｋ（γ、δ）を編集するｅｄｉｔパッチＡ２の積に分解される。以下では、このようなパッチの積をＡ１＊Ａ２と表わす。
【００３８】
図６に正規化処理の一例を説明する。図６によると、正規化前のパッチ集合は、ファイルａを追加するパッチＢとファイルａを削除するパッチＧとの間に挟まれたパッチＣ、Ｄ、Ｅ、Ｆから成るパッチ積を部分集合として含む。ここで、パッチＢとパッチＧの間に挟まれたパッチのうち、ファイルａに作用するパッチＤ、Ｅ、Ｆの効果は、ファイルａを削除するパッチＧを適用することによって無効となる。よって、パッチＢ、Ｄ、Ｅ、Ｆ、Ｇは除去することができる。つまり、一般にａｄｄ（ａ）とｄｅｌ（ａ）およびその区間のｅｄｉｔ（ａ）パッチは除去することができる。
【００３９】
パッチ同報部１２は、パッチ集合をパッチ正規化部１１から受け取り、他の全てのクライアント６０ｑ〜６０ｔ上のパッチ再構成部１０へ同報通信する。他の全てのクライアント６０ｑ〜６０ｔ上のパッチ再構成部１０におけるパッチ演算部１４は、同報通信により送信されたパッチ集合を受け取り、リポジトリ４０へコミットされたパッチとマージが可能なパッチ集合を求める。
【００４０】
共通パッチ生成部１３は、他の全てのクライアント６０ｑ〜６０ｔ上のパッチ再構成部１０で求められたマージ可能なパッチの集合（「マージ可能パッチ」という。）を収集し、全てのクライアント６０ｐ〜６０ｔ上のリポジトリ４０に共通してマージ可能なパッチの集合（「共通パッチ」という。）を生成する。例えば、作成したパッチ集合が［Ａ、Ｂ、Ｃ、Ｄ、Ｅ］であり、これを他のクライアント６０ｑ、６０ｒへマージしようとしている場合を考える。それぞれのクライアント６０ｑ、６０ｒにおけるマージ可能パッチが、クライアント６０ｑにおいて［Ａ、Ｂ、Ｃ、Ｄ］、クライアント６０ｒにおいて［Ｃ、Ｄ、Ｅ］であったとすると、共通パッチは［Ｃ、Ｄ］となる。
【００４１】
パッチ演算部１４は、入力としてパッチ集合を受け取り、パッチの差分情報にもとづいて、リポジトリ４０中のパッチとの競合判定や依存判定、およびリポジトリ４０へのマージ処理を行う。
【００４２】
２つのパッチが競合するのは、２つのパッチが同じファイルａを操作しようとしている場合において、一方のパッチ管理によって他方のパッチが適用できなくなるときと、一方のパッチの効果が他方のパッチで無効になってしまうときである。このような競合を起こすパッチの組み合わせは「ｅｄｉｔ（ａ）＊ｅｄｉｔ（ａ）」、「ｅｄｉｔ（ａ）＊ｄｅｌ（ａ）」、「ｎｅｗ（ａ）＊ｄｅｌ（ａ）」、「ｄｅｌ（ａ）＊ｅｄｉｔ（ａ）」、「ｄｅｌ（ａ）＊ｎｅｗ（ａ）」の５通りである。
【００４３】
図７に「ｅｄｉｔ（ａ）＊ｅｄｉｔ（ａ）」パッチ積がマージ可能な場合と競合を起こす場合の例を示す。パッチＰ１、Ｐ２はそれぞれｅｄｉｔ（ａ）パッチであり、それぞれｈｕｎｋ（α、β）、ｈｕｎｋ（γ、δ）を編集するものとする。ここで図７（ａ）によると、ｈｕｎｋ（α、β）とｈｕｎｋ（γ、δ）が重ならない場合、すなわち、β＜γ又はδ＜αの場合、それぞれのパッチが編集する領域は重ならないので、マージ可能である。逆に図７（ｂ）によると、これが成りたたない場合（すなわち、γ≦βかつα≦δである場合）、それぞれのパッチが編集する領域が重なるので競合を起こす。
【００４４】
その他に競合を起こす例として、「ｅｄｉｔ（ａ）＊ｄｅｌ（ａ）」、「ｎｅｗ（ａ）＊ｄｅｌ（ａ）」、「ｄｅｌ（ａ）＊ｅｄｉｔ（ａ）」、「ｄｅｌ（ａ）＊ｎｅｗ（ａ）」の４通りがある。「ｅｄｉｔ（ａ）＊ｄｅｌ（ａ）」では、ｅｄｉｔ（ａ）パッチによる編集がｄｅｌ（ａ）パッチによって無効になるので、競合となる。「ｎｅｗ（ａ）＊ｄｅｌ（ａ）」では、ｎｅｗ（ａ）によって作成したファイルａがｄｅｌ（ａ）によって削除されてしまうため、競合となる。「ｄｅｌ（ａ）＊ｅｄｉｔ（ａ）」では、ｄｅｌ（ａ）で削除したファイルａをｅｄｉｔ（ａ）で編集することはできないので、競合となる。「ｄｅｌ（ａ）＊ｎｅｗ（ａ）」では、ｄｅｌ（ａ）で削除したファイルａをｎｅｗ（ａ）で作成し直すことになり、競合を引き起こす。
【００４５】
２つのパッチ間に依存関係が発生するのは、ｎｅｗ（ａ）とそれに続くｅｄｉｔ（ａ）の組み合わせである。図８に依存関係の例を示す。ｅｄｉｔ（ａ）パッチを適用するためには、これに先立ってｎｅｗ（ａ）パッチが適用され、ファイルａが作成されていなければならない。このため、ｅｄｉｔ（ａ）パッチであるパッチＢ及びパッチＥはｎｅｗ（ａ）パッチであるパッチＡに依存する。
【００４６】
マージ処理は、あるファイルへ適用するパッチを同じファイルで別のパッチが適用された後に適用するために変形する処理である。図９は、パッチのマージ処理の例を示す。図９によると、パッチＡ、Ｂはそれぞれ同じファイルａに適用されるパッチである。ここで、パッチＡをパッチＢが当たった後に適用する（すなわち、マージする）ためには、パッチＡを変形しなければならない。なぜなら、ファイルａの中身はパッチＢの適用によって変化しているため、事前に変化分のオフセット変換を行わなければならないからである。以後の説明では、ファイルａへパッチＢが当たった後のファイルの状態をコンテキストと呼び、パッチＢが当たる前の状態と区別する。
【００４７】
図１０に、パッチＡをコンテキストに適用する場合の具体的なマージ処理を示す。パッチＢではｈｕｎｋ（γ、δ）を編集しているので、パッチＢの適用後、ファイルａはｈｕｎｋ（γ、δ）の範囲分、すなわち、（δ−γ＋１）行分前又は後ろにずれる。つまり、パッチＢがｈｕｎｋ（γ、δ）を挿入するパッチであった場合、ファイルａのγ行目以降は後ろにずれる。逆に、パッチＢがｈｕｎｋ（γ、δ）を削除するパッチであった場合、ファイルａのδ＋１行目以降は前にずれる。このずれをｏｆｆｓｅｔ（ｈｕｎｋ（γ、δ））で表す。ｏｆｆｓｅｔを使うと、パッチＡをマージのために変形したパッチＡ’は、ｈｕｎｋ（α＋ｏｆｆｓｅｔ（ｈｕｎｋ（γ、δ））、β＋ｏｆｆｓｅｔ（ｈｕｎｋ（γ、δ）））を編集することになる。マージ処理はこのオフセット変換を行う処理である。
【００４８】
分散ロック部２０は、全てのクライアント６０ｐ〜６０ｔへのマージ処理を排他的に行うために、マージ処理中のパッチのコミットおよびチェックアウト処理を全てのクライアント６０ｐ〜６０ｔ上のリポジトリ４０で禁止するための手段である。
【００４９】
なお、パッチ管理装置３０は、ユーザインタフェース５０を実現する装置と同一又は別のコンピュータを基本ハードウェアとして用いることもできる。そして、パッチ再構成部１０及びリポジトリ４０は、上記のコンピュータに搭載されたプロセッサにプログラムを実行させることにより実現することもできる。
【００５０】
パッチ管理装置３０は、上記のプログラムをコンピュータに予めインストールすることで実現されても良いし、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯなど）、半導体メモリなどのリムーバブルな記憶媒体に記録し、あるいはＬＡＮやインターネット等のネットワークを介して上記のプログラムを配布し、このプログラムをコンピュータに適宜インストールすることによって実現してもよい。
【００５１】
パッチ記憶装置４１は、上記のコンピュータに内蔵されたメモリやハードディスク装置等の記憶デバイス、上記のコンピュータに外付けされたメモリやハードディスク装置などの記憶デバイス、さらにはフレキシブルディスク等のリムーバブルな記憶媒体などを適宜利用して実現することができる。
【００５２】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼動しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が本実施の形態を実現するための各処理の一部を実行するようにしても良い。記憶媒体は１つに限らず、複数の媒体から本実施の形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【００５３】
上記のコンピュータは、記憶媒体に記憶されたプログラムに基づき、第１の実施の形態における各処理を実行するものであって、パーソナル・コンピュータ等の１つからなる装置、複数の装置がネットワーク接続されたコンピュータ等の何れの構成であっても良い。上記のコンピュータは、パーソナル・コンピュータに限らず、情報処理機器に含まれる演算処理装置、マイクロコンピュータ等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【００５４】
次に、図１１のシーケンス図を参照して、本実施形態に係るパッチ管理装置の動作について詳細に説明する。ここでは、ネットワーク７０を介して互いに通信可能なクライアント６０ｐ〜６０ｔのうち、一例として、クライアント６０ｐにおいて生成（又はクライアント６０ｐに対して入力）されたパッチを、他のクライアント６０ｑ〜６０ｔのリポジトリ４０に反映させる場合を想定する。クライアント６０ｐに備えたパッチ管理装置３０は、バッチジョブとして一定の周期で、又は、ユーザインタフェース５０からの指示に応じて、図１１に示す処理を起動する。
【００５５】
ユーザインタフェース５０は、ネットワーク７０に接続された全てのクライアント６０ｐ〜６０ｔのリポジトリ４０に対する変更点となるパッチ集合を作成し、パッチ管理装置３０へ全体マージ処理を要求する。パッチ集合は、パッチ正規化部１１への入力として渡され、例えば、図５及び図６において示した正規化が施される（ステップＳ１１）。
【００５６】
パッチ管理装置３０は、全体マージ処理全体を安全に行うために、分散ロック部２０を通じて、全てのクライアント６０ｐ〜６０ｔのリポジトリ４０をロックする（ステップＳ１２、Ｓ２１）。ロック中は、リポジトリ４０からのチェックアウトおよびコミット処理は禁止される。
【００５７】
パッチ管理装置３０は、正規化済みパッチ集合を他の全クライアント６０ｑ〜６０ｔへ同報通信する（ステップＳ１３）。同報通信先の各クライアント６０ｑ〜６０ｔでは、同報通信されたパッチ集合を受信する（ステップＳ２２）。
【００５８】
同報通信先の各クライアント６０ｑ〜６０ｔのパッチ演算部１４は、ステップＳ２２において受信したパッチ集合のうちリポジトリ４０へとマージ可能なパッチ集合（マージ可能パッチ）を算出する（ステップＳ２３）。各クライアント６０ｑ〜６０ｔは、ステップＳ２３において求めたマージ可能パッチを同報通信元のクライアント６０ｐの共通パッチ生成部１３へと返信する（ステップＳ２４）。クライアント６０ｐのパッチ管理装置３０に備えた共通パッチ生成部１３は、他のクライアント６０ｑ〜６０ｔから送信されたマージ可能パッチを収集する（ステップＳ１４）。
【００５９】
パッチ管理装置３０では、マージ可能パッチを収集した後、共通パッチ生成部１３が全てのクライアント６０に共通してマージ可能なパッチの集合（「共通パッチ」）を求める（ステップＳ１５）。パッチ管理装置３０は、ステップＳ１５において求められた共通パッチをパッチ同報部１２を通じて他の全てのクライアント６０ｑ〜６０ｔへ同報通信を行う（ステップＳ１６）。同報通信先の各クライアント６０ｑ〜６０ｔでは、同報通信された共通パッチを受信する（ステップＳ２５）。
【００６０】
全てのクライアント６０ｐ〜６０ｔ上のパッチ管理装置３０では、ステップＳ１５において求められた共通パッチをリポジトリ４０へマージするために、パッチ演算部１４を通じてマージ処理を行う（ステップＳ１７、Ｓ２６）。また、全てのクライアント６０ｐ〜６０ｔ上のパッチ管理装置３０は、リポジトリ操作部４２を介して、ステップＳ１７およびＳ２６において変換された共通パッチをリポジトリ４０へコミットする（ステップＳ１８、Ｓ２７）。
【００６１】
パッチ管理装置３０では、分散ロック部２０を通じて分散ロックを解除する（ステップＳ１９、Ｓ２８）。コミットが完了した後、全てのクライアント６０ｐ〜６０ｔは図１１に示す処理を終了する。
【実施例１】
【００６２】
次に、本発明の第１の実施例を、図面を参照して説明する。本実施例は、入力装置としてキーボードを、データ処理装置としてパーソナル・コンピュータを、データ記憶装置として磁気ディスク装置を、出力装置としてディスプレイを備えている。
【００６３】
パーソナル・コンピュータは、リポジトリ操作部４２、分散ロック部２０、パッチ正規化部１１、パッチ同報部１２、共通パッチ生成部１３、パッチ演算部１４、ユーザインタフェース５０として機能する中央演算処理装置を有している。また、パッチ記憶装置４１として機能する磁気ディスク装置を備えている。
【００６４】
ここで、ユーザインタフェース５０から図１２に示されるＡからＨまでのパッチ集合がパッチ再構成部１０へ渡され、全体マージ要求が出されたとする。以後、この全体マージ要求を出したクライアント（一例として、６０ｐ）をマスターサイトと呼ぶ。また、全体マージに参加する他のクライアント（一例として、６０ｑ、６０ｒ）をサイトＸ、サイトＹと呼ぶ。全体マージ実行前の時点で、各サイトのリポジトリ４０にコミットされたパッチの状態を図１３とする。パッチ集合はユーザインタフェース５０からパッチ正規化部１１へと渡される。
【００６５】
パッチ正規化部１１は、与えられたパッチを正規化する。ここでは、図１２に示されるパッチのうちＥが「ｎｅｗ（ｄ）」、Ｈが「ｄｅｌ（ｄ）」となっており、これらのパッチとその間に挟まれるパッチＦ「ｅｄｉｔ（ｄ）」を削除してもパッチ全体としての作用は変わらない。よって、パッチ正規化部１１はこれらのパッチを入力のパッチ集合から除去する。正規化されたパッチ集合は図１４に示されるようになる。
【００６６】
パッチ正規化部１１は、分散ロック部２０を通じて全体マージに参加する全サイトのリポジトリ４０をロックする。ロックが完了すると、正規化済みパッチ集合をパッチ同報部１２を通じてサイトＸ、Ｙへと同報通信する。
【００６７】
サイトＸ、Ｙは、パッチ演算部１４を介して、同報通信された正規化済みパッチ集合を取得し、ローカルのパッチと競合を起こすファイルをパッチ演算で求める。サイトＸにおけるパッチ演算を図１５に示す。まず、全体マージされたパッチ集合内での依存関係を求める。パッチＣは「ｎｅｗ（ｃ）」であり、ファイルｃを新たに生成するパッチである。パッチＤは「ｅｄｉｔ（ｃ）」であり、ファイルｃを編集するパッチである。このとき、依存関係の定義よると、パッチＤはパッチＣに依存する。
【００６８】
次に、サイトＸのパッチ集合との競合関係を求める。競合関係の定義より、競合するパッチはファイルｃを削除するパッチＸＥと、ファイルｃを生成するパッチＣである。ここで、パッチＤはパッチＣに依存するので、さらにパッチＤもパッチＸＥと競合する。また、同じ「ｅｄｉｔ（ａ）」であるパッチＸＤとパッチＢ、Ｇは競合する可能性があるが、ここでは、図７に示される競合判定によって競合しないものと判定されたとする。以上のパッチ演算より、サイトＸのパッチ集合と競合しないパッチ集合は［Ａ、Ｂ、Ｇ］となる。
【００６９】
サイトＹにおけるパッチ演算を図１６に示す。競合する可能性のあるパッチの組合せとして、同じ「ｅｄｉｔ（ｂ）」であるパッチＹＣとパッチＡがある。ここで、図７に示される競合判定によりこれらが競合すると判定されたとする。この場合、サイトＹのパッチ集合と競合しないパッチ集合（すなわち、マージ可能パッチ）は［Ｂ、Ｃ、Ｄ、Ｇ］となる。
【００７０】
サイトＸおよびサイトＹは競合を起こさないパッチ集合をパッチ演算後、パッチ演算部１４を通じてマスターサイトへ返信する。
【００７１】
マスターサイトは、競合を起こさないパッチ集合をサイトＸおよびサイトＹから共通パッチ生成部１３を通じて収集する。収集が完了後、共通パッチ生成部１３はそれぞれのパッチ集合の積集合（「共通パッチ」）を求める。例えば、この例ではサイトＸにおいて競合を起こさないパッチ集合は［Ａ、Ｂ、Ｇ］であり、サイトＹにおいて競合を起こさないパッチ集合は［Ｂ、Ｃ、Ｄ、Ｇ］であるから、共通パッチは［Ｂ、Ｇ］となる。
【００７２】
求められた共通パッチはパッチ同報部１２を通じてサイトＸ、Ｙへ同報通信される。送付先のサイトＸ、Ｙではそれぞれ、マージ処理が行われる。例として、図１７にサイトＸでのマージ処理を示す。共通パッチ［Ｂ、Ｇ］をサイトＸのコンテキストにマージするために、図１０に示されるパッチの変形処理を行う。
【００７３】
変形された共通パッチは、サイトＸのリポジトリ操作部４２を通じてサイトＸのリポジトリ４０にコミットされ、マージが完了する。
【００７４】
図１８に示すように、サイトＸ、Ｙでのマージ処理と同様に、共通パッチはマスターサイトのパッチ演算部１４へと渡され、リポジトリ４０中のパッチ集合とマージのためのパッチ演算による変換が行われる。その後、リポジトリ操作部４２を通じてパッチ記憶装置４１へコミットされる。
【００７５】
コミット完了後、パッチ演算部１４は分散ロックを解除し、パッチ集合の全体へのマージが完了する。
【００７６】
以上、第１の実施形態及び第１の実施例では、ファイルへパッチを適用する前後の差分をｈｕｎｋと呼ばれる行単位の差分で示したが、ＸＭＬや構文木など適切に差分の定義が可能な構造化されたデータ形式によっても、パッチ演算処理を定義し全体へマージすることができる。
【００７７】
また、リポジトリ４０は、コミットされたパッチを保持するためのパッチ記憶装置４１と、パッチ記憶装置４１へパッチをコミットまたはチェックアウトするためのリポジトリ操作部４２から構成されていたが、リポジトリ操作部４２はリポジトリ４０の外にあっても良い。
【００７８】
また、ユーザインタフェース５０がコミットするパッチ集合がすでに正規化されており、パッチ演算部１４が直接処理可能な場合には、パッチ正規化部１１は正規化処理を行わず、パッチ集合を直接パッチ同報部１２への入力として渡しても良い。
【実施例２】
【００７９】
本発明の第２の実施例について図面を参照して説明する。図１９は本発明の第２の実施例に係るパッチ管理装置を備えたクライアントの構成を示すブロック図である。
【００８０】
パッチ管理装置３０は、ネットワークを介して互いに通信可能な複数のクライアント６０ｐ〜６０ｔのそれぞれのリポジトリ４０に対するパッチを管理する。パッチ管理装置３０は、共通パッチ生成部１３及びパッチ演算部１４を備える。共通パッチ生成部１３は、クライアント６０ｐ〜６０ｔそれぞれのリポジトリ４０のいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する。パッチ演算部１４は、共通パッチをリポジトリ４０に格納されたデータにマージする。
【００８１】
本実施例に係るパッチ管理装置によって、ネットワークを介して互いに通信可能な複数のクライアントの間で、パッチ間の競合及び個々のクライアントにおけるパッチのマージ作業を回避しつつ、パッチを当てることができる。
【００８２】
以上の記載は実施例に基づいて行ったが、本発明は、上記実施例に限定されるものではない。
【産業上の利用可能性】
【００８３】
本発明のパッチ管理装置は、ファイルの編集を複数人数で並行に行うバージョン管理システムに対して適用することができる。
【図面の簡単な説明】
【００８４】
【図１】本発明の実施形態に係るパッチ管理装置を備えたクライアントの構成を示すブロック図である。
【図２】ネットワークを介して互いに通信可能な複数のクライアントの間におけるパッチ管理を説明するための図である。
【図３】ファイルを編集するパッチｅｄｉｔ（）の概念図である。
【図４】パッチ集合の構成を示す図である。
【図５】パッチの正規化処理を説明するための図である。
【図６】パッチの正規化処理の説明するための図である。
【図７】パッチの競合判定処理の説明をするための図である。
【図８】パッチの依存関係を示す図である。
【図９】パッチのマージ処理の例を示す図である。
【図１０】パッチのマージ処理のための変形処理を示す図である。
【図１１】本発明の実施形態の全体の動作を示すシーケンス図である。
【図１２】全体へマージするパッチ集合の一例を示す図である。
【図１３】リポジトリにコミットされたパッチ集合の一例を示す図である。
【図１４】正規化処理を行ったパッチ集合の一例を示す図である。
【図１５】パッチの競合判定の一例を示す図である。
【図１６】パッチの競合判定の一例を示す図である。
【図１７】パッチのマージ処理の一例を示す図である。
【図１８】パッチのマージ処理の一例を示す図である。
【図１９】本発明の第２の実施例に係るパッチ管理装置を備えたクライアントの構成を示すブロック図である。
【符号の説明】
【００８５】
１０ パッチ再構成部
１１ パッチ正規化部
１２ パッチ同報部
１３ 共通パッチ生成部
１４ パッチ演算部
２０ 分散ロック部
３０ パッチ管理装置
４０ リポジトリ
４１ パッチ記憶装置
４２ リポジトリ操作部
５０ ユーザインタフェース
６０、６０ｐ〜６０ｔ クライアント
７０ ネットワーク
【技術分野】
【０００１】
本発明はパッチ管理装置、パッチ管理方法及びパッチ管理プログラムに関し、特にネットワーク間で分散管理されたファイル集合について、競合を起こすことなくパッチをファイル集合へ反映させることを可能にするパッチ管理装置、パッチ管理方法及びパッチ管理プログラムに関する。
【背景技術】
【０００２】
従来から、プログラムを共同開発する際に、ソースコードのコピーを開発者全員がリポジトリに設けた記憶装置に保持し、ファイルに対して行われた変更点のみを開発者間でやりとりしつつ開発を進める方法が利用されている。共同開発へ参加する開発者は、始めにソースコードのコピーを手元のリポジトリへコピーしておいて、変更を行った際にはパッチと呼ばれる変更点のみを他の開発者へ配布することで、ネットワークを介した分散環境においても、一つのプログラムを効率良く共同開発することができる。
【０００３】
特許文献１に開示されたパッチ管理装置においては、パッチをファイルシステムへの変更点として抽出し、パッチ適用対象のファイルシステムへ上書きしていた。具体的には、ファイルシステムの変更前と変更後それぞれの状態を持つ仮想マシン（バーチャルマシン）を作成し、仮想マシン中のファイルそれぞれについて、ファイルの追加や削除、ファイルのタイムスタンプ、サイズ及びハッシュ値の変化を検査することによって変更されたファイル集合を抽出し、このファイル集合をパッチとしてパッチ適用対象のファイルシステムへ上書きしていた。
【０００４】
特許文献２に開示されたパッチ管理装置においては、ソースコードを管理する中央リポジトリ（ソースコード管理サーバ）によって、クライアントから受信したソースコードの変更点をソースコードの構文解析結果である構文ツリーへのパッチとして管理し、クライアントは必要に応じてソースコード管理サーバ上の更新されたパッチを手元のリポジトリへ適用することでソースコード管理を行っていた。
【０００５】
【特許文献１】特開２００３−２９６１３２号公報
【特許文献２】特開２００５−３４６６６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
以下の分析は、本発明者によってなされたものである。従来のパッチ管理装置では、パッチを他の全てのリポジトリへ反映するために、特許文献１のように変更されたファイル集合をパッチとして上書きする方法や、特許文献２のようにパッチを一元的に管理する中央リポジトリを経由する方法があった。
【０００７】
特許文献１の方法によれば、パッチを他のリポジトリへ反映する際には、パッチであるファイル集合がパッチ適用対象のリポジトリへ上書きされる。すなわち、リポジトリごとの変更点はパッチの上書きにより失われる可能性がある。したがって、リポジトリごとの変更点を残しつつ、マージ可能なパッチのみを適用することを目的としたパッチ管理には向いていない。
【０００８】
特許文献２の方法によれば、ローカルに作成したパッチを他の全リポジトリへ反映するためには、いったん中央リポジトリへすべてのパッチをコミットと呼ばれる操作で登録しておき、他の全てのリポジトリ上でこのパッチを反映させる操作を実行する必要があった。
【０００９】
このため、第１の問題点として、パッチを作成したユーザが一元的に反映操作を実行できず、他のリポジトリを備えたマシンへリモートログインするなどして反映しなければならないという問題があった。また、パッチを反映させる際には、ローカルで独自に作成したパッチと中央リポジトリから取得したパッチとが競合を起こす可能性がある。このため、第２の問題点として、各リポジトリ上でマージと呼ばれる修正処理を行う必要があった。
【００１０】
そこで、ネットワークを介して互いに通信可能な複数のクライアントの間で、パッチ間の競合及び個々のクライアントにおけるパッチのマージ作業を回避しつつ、パッチを当てることのできるパッチ管理方法を提供することが課題となる。
【課題を解決するための手段】
【００１１】
本発明の第１の視点に係るパッチ管理装置は、
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理するパッチ管理装置であって、
前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出するように構成された共通パッチ生成部と、
前記共通パッチを前記リポジトリに格納されたデータにマージするように構成されたパッチ演算部と、を備えることを特徴とする。
【００１２】
第１の展開形態のパッチ管理装置は、
前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するように構成されたパッチ抽出部を備え、
前記共通パッチ生成部は、前記マージ可能パッチを参照し、その共通部分を共通パッチとして抽出するように構成されることが好ましい。
【００１３】
第２の展開形態のパッチ管理装置は、
パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化部を備え、
前記パッチ抽出部は、前記パッチ正規化部によって分解されたパッチの積を参照し、前記マージ可能パッチを抽出するように構成されることが好ましい。
【００１４】
第３の展開形態のパッチ管理装置は、
前記リポジトリのすべてに対する操作をロックするとともに、操作のロックを解除するように構成された分散ロック部を備えることが好ましい。
【００１５】
本発明の第２の視点に係るパッチ管理方法は、
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理するパッチ管理方法であって、
（ａ）前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する共通パッチ生成工程と、
（ｂ）前記共通パッチを前記リポジトリに格納されたデータにマージするパッチ演算工程と、を含むことを特徴とする。
【００１６】
第４の展開形態のパッチ管理方法は、
（ｃ）前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するパッチ抽出工程を含み、
前記共通パッチ生成工程（ａ）において、前記マージ可能パッチの共通部分を共通パッチとして抽出することが好ましい。
【００１７】
第５の展開形態のパッチ管理方法は、
（ｄ）パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化工程を含み、
前記パッチ抽出工程（ｃ）において、前記パッチ正規化工程（ｄ）において分解されたパッチの積に基づいて前記マージ可能パッチを抽出することが好ましい。
【００１８】
第６の展開形態のパッチ管理方法は、
前記リポジトリのすべてに対する操作をロックする工程と、
そのロックを解除する工程と、をそれぞれ最初と最後に含むことが好ましい。
【００１９】
本発明の第３の視点に係るパッチ管理プログラムは、
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理する処理をコンピュータに実行させるパッチ管理プログラムであって、
（ａ）前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する共通パッチ生成処理と、
（ｂ）前記共通パッチを前記リポジトリに格納されたデータにマージするパッチ演算処理と、をコンピュータに実行させることを特徴とする。
【００２０】
第７の展開形態のパッチ管理プログラムは、
（ｃ）前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するパッチ抽出処理をコンピュータに実行させ、
前記共通パッチ生成処理（ａ）において、前記マージ可能パッチの共通部分を共通パッチとして抽出する処理をコンピュータに実行させることが好ましい。
【００２１】
第８の展開形態のパッチ管理プログラムは、
（ｄ）パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化処理をコンピュータに実行させ、
前記パッチ抽出処理（ｃ）において、前記パッチ正規化処理（ｄ）において分解されたパッチの積に基づいて前記マージ可能パッチを抽出する処理をコンピュータに実行させることが好ましい。
【００２２】
第９の展開形態のパッチ管理プログラムは、
前記リポジトリのすべてに対する操作をロックする処理と、
そのロックを解除する処理と、をそれぞれ最初と最後にコンピュータに実行させることが好ましい。
【発明の効果】
【００２３】
本発明により、ネットワークを介して互いに通信可能な複数のクライアントの間で、パッチ間の競合及び個々のクライアントにおけるパッチのマージ作業を回避しつつ、パッチを当てることのできるパッチ管理方法が提供される。すなわち、作成したパッチを他の全てのリポジトリへ反映させたい場合、他のリポジトリへパッチ反映やマージを依頼することなく、全リポジトリへマージ可能なパッチをパッチ演算に基づいて判定し、マージすることができる。
【００２４】
本発明により、例えば、異なる管理者によって個別に管理されるマシン間において設定ファイルを共有する場合において、重要な設定変更を他のマシンへ反映させる必要が生じた際に、他のマシンの管理者に手間をかけることなく、重要な設定の変更点のみを複数マシンに対して競合を起こすことなく反映させることができる。
【発明を実施するための最良の形態】
【００２５】
本発明の実施形態について図面を参照して詳細に説明する。図１は、本発明の第１の実施の形態に係るパッチ管理装置３０を備えたクライアント６０の構成を示すブロック図である。クライアント６０は、パッチ管理装置３０、リポジトリ４０、ユーザインタフェース５０を備える。
【００２６】
パッチ管理装置３０はパッチの管理を行う。リポジトリ４０はコミットされたパッチを保持する。ユーザインタフェース５０は、パッチのコミットや全リポジトリへのパッチのマージを指示し、またマージ結果をユーザへ表示する。
【００２７】
図２は、ネットワークを介して互いに通信可能な複数のクライアントの間におけるパッチ管理を説明するための図である。図２において、クライアント６０ｐは、ネットワーク７０を通じて他のクライアント６０ｑ〜６０ｔと通信可能である。すべてのクライアント６０ｐ〜６０ｔは、初期状態として、共通した同一のパッチ集合を自身のリポジトリ４０に保持する。ある１つのクライアント６０ｐが新たなパッチを作成し、他のクライアント６０ｑ〜６０ｔ上のリポジトリ４０へ反映させたい場合には、パッチ管理装置３０を通じて他のすべてのクライアント６０ｑ〜６０ｔ上のリポジトリ４０に対するマージ処理を行う。
【００２８】
パッチ管理装置３０は、パッチ再構成部１０と分散ロック部２０を備える。パッチ再構成部１０は、パッチ集合を入力とし、他の全てのリポジトリでパッチが競合を起こさないための再構成を行う。分散ロック部２０は、他の全てのリポジトリ４０のロックを行う。
【００２９】
ユーザインタフェース５０は、ユーザが作成したパッチを同じクライアント６０上のリポジトリ４０、もしくはネットワーク７０を通じて接続された他のクライアント６０上のリポジトリ４０へマージするためのインタフェースである。例えば、ユーザインタフェース５０を通じてコミットを指示すると、ユーザが作成したパッチをリポジトリ４０へコミットする。また、マージを指示すると、ネットワーク７０を通じて接続された他の全てのクライアント６０ｑ〜６０ｔのリポジトリ４０へユーザが作成したパッチをマージする。また、マージの後、マージの成功や失敗、マージ時にどのパッチが実際にマージできたか等の実行結果をユーザへ表示する。
【００３０】
リポジトリ４０は、パッチ記憶装置４１とリポジトリ操作部４２を備える。パッチ記憶装置４１は、コミットされたパッチ集合を保持するための記憶手段である。リポジトリ操作部４２はパッチ集合を入力とし、パッチ記憶装置４１へパッチを登録し、パッチ演算部１４からの要求に応じて、コミットされたパッチ集合を取り出す。
【００３１】
リポジトリ４０に対して変更を加えるパッチの種類は、「ファイルの追加（ｎｅｗ）」、「ファイルの削除（ｄｅｌｅｔｅ）」、「ファイル内容の編集（ｅｄｉｔ）」の３通りである。「ファイルの追加」パッチは、新たなファイルａをリポジトリ４０に追加する。
以下ではこれを「ｎｅｗ（ａ）」パッチと呼ぶ。「ファイルの削除」パッチはリポジトリ４０中のファイルａを削除する。以下ではこれを「ｄｅｌ（ａ）」パッチと呼ぶ。「ファイル内容の編集」パッチはリポジトリ４０中のファイルａの指定された部分へ行を追加または削除する。以下ではこれを「ｅｄｉｔ（ａ）」パッチと呼ぶ。
【００３２】
図３にｅｄｉｔ（）パッチによって行が追加または削除される例を示す。図３（ａ）によると、このｅｄｉｔ（）パッチはファイルの指定された部分へ行を追加するパッチである。ファイルにｅｄｉｔ（）パッチを適用することで、ファイルのα行目からβ行目の部分に行が追加される。図３（ｂ）によると、このｅｄｉｔ（）パッチはファイルの指定された部分から行を削除するパッチである。ファイルにｅｄｉｔ（）パッチを適用することで、ファイルのα行目からβ行目の部分が削除される。以下では、この追加または削除されるα行目からβ行目までの範囲をｈｕｎｋ（α、β）と呼ぶ。
【００３３】
パッチ集合とは、リポジトリ４０に変更を加えるパッチの順序付き集合である。図４にパッチ集合の構成を示す。図４に示されるように、パッチは属性として適用順序を持ち、パッチ集合を適用する際にはこの適用順序の順番にパッチが適用される。パッチを適用する順番は厳密に守られる必要がある。これは、パッチ集合内のパッチの順序を入れ替えた場合には、パッチの適用に失敗したり、パッチ集合がリポジトリ４０に行う変更内容が変わったりするためである。すなわち、あるファイルに２つのパッチＡ、Ｂを順に適用する操作をＡとＢの積ＡＢで表すものとすると、パッチの積の間には、交換則が成り立たない場合がある（すなわち、ＡＢ≠ＢＡ）。
【００３４】
パッチ順序の入れ替えによって、パッチの適用が失敗する例として、パッチＡが「ａｄｄ（ａ）」パッチで、パッチＢが「ｅｄｉｔ（ａ）」パッチである場合が挙げられる。この場合、Ａ、Ｂの順にパッチを適用することはできるが、Ｂ、Ａの順にパッチを適用することはできない。ファイルａがパッチＡにより追加される前に、ファイルａへ行を追加することはできないからである。
【００３５】
一方、パッチ順序の入れ替えにより変更内容が変わってしまう例として、パッチＣが「ｈｕｎｋ（２０、２１）を追加するｅｄｉｔ（ｂ）」パッチで、パッチＤが「ｈｕｎｋ（１０、１１）を追加するｅｄｉｔ（ｂ）」パッチである場合が挙げられる。Ｃ、Ｄ、の順にパッチを適用した結果と、Ｄ、Ｃの順にパッチを適用した結果は異なる。これは、以下の理由による。すなわち、Ｃ、Ｄの順にパッチを適用した場合、パッチ適用前のファイルｂの１０行目、２０行目に新たな行が挿入される。一方、Ｄ、Ｃの順にパッチを適用した場合、Ｄを適用した段階で元々のファイルｂの１１行目以降の行は１行ずつずれるため、Ｃで追加される行はもともとのファイルｂの１８行目と１９行目の間に挿入される。
【００３６】
パッチ再構成部１０は、パッチ正規化部１１と、パッチ同報部１２と、共通パッチ生成部１３と、パッチ演算部１４を備える。パッチ正規化部１１は、ユーザインタフェース５０から渡されたパッチ集合を変形し、ｎｅｗ（）、ｄｅｌ（）、および１つのｈｕｎｋを編集するｅｄｉｔパッチの積に分解する。また、パッチ集合の中から不要なパッチを削除する。これらを正規化処理と呼ぶ。
【００３７】
図５に正規化処理の一例を説明する。図５によると、正規化前のパッチＡはｈｕｎｋ（α、β）、およびｈｕｎｋ（γ、δ）を編集するｅｄｉｔパッチである。これらのパッチを正規化すると、ｈｕｎｋ（α、β）を編集するｅｄｉｔパッチＡ１と、ｈｕｎｋ（γ、δ）を編集するｅｄｉｔパッチＡ２の積に分解される。以下では、このようなパッチの積をＡ１＊Ａ２と表わす。
【００３８】
図６に正規化処理の一例を説明する。図６によると、正規化前のパッチ集合は、ファイルａを追加するパッチＢとファイルａを削除するパッチＧとの間に挟まれたパッチＣ、Ｄ、Ｅ、Ｆから成るパッチ積を部分集合として含む。ここで、パッチＢとパッチＧの間に挟まれたパッチのうち、ファイルａに作用するパッチＤ、Ｅ、Ｆの効果は、ファイルａを削除するパッチＧを適用することによって無効となる。よって、パッチＢ、Ｄ、Ｅ、Ｆ、Ｇは除去することができる。つまり、一般にａｄｄ（ａ）とｄｅｌ（ａ）およびその区間のｅｄｉｔ（ａ）パッチは除去することができる。
【００３９】
パッチ同報部１２は、パッチ集合をパッチ正規化部１１から受け取り、他の全てのクライアント６０ｑ〜６０ｔ上のパッチ再構成部１０へ同報通信する。他の全てのクライアント６０ｑ〜６０ｔ上のパッチ再構成部１０におけるパッチ演算部１４は、同報通信により送信されたパッチ集合を受け取り、リポジトリ４０へコミットされたパッチとマージが可能なパッチ集合を求める。
【００４０】
共通パッチ生成部１３は、他の全てのクライアント６０ｑ〜６０ｔ上のパッチ再構成部１０で求められたマージ可能なパッチの集合（「マージ可能パッチ」という。）を収集し、全てのクライアント６０ｐ〜６０ｔ上のリポジトリ４０に共通してマージ可能なパッチの集合（「共通パッチ」という。）を生成する。例えば、作成したパッチ集合が［Ａ、Ｂ、Ｃ、Ｄ、Ｅ］であり、これを他のクライアント６０ｑ、６０ｒへマージしようとしている場合を考える。それぞれのクライアント６０ｑ、６０ｒにおけるマージ可能パッチが、クライアント６０ｑにおいて［Ａ、Ｂ、Ｃ、Ｄ］、クライアント６０ｒにおいて［Ｃ、Ｄ、Ｅ］であったとすると、共通パッチは［Ｃ、Ｄ］となる。
【００４１】
パッチ演算部１４は、入力としてパッチ集合を受け取り、パッチの差分情報にもとづいて、リポジトリ４０中のパッチとの競合判定や依存判定、およびリポジトリ４０へのマージ処理を行う。
【００４２】
２つのパッチが競合するのは、２つのパッチが同じファイルａを操作しようとしている場合において、一方のパッチ管理によって他方のパッチが適用できなくなるときと、一方のパッチの効果が他方のパッチで無効になってしまうときである。このような競合を起こすパッチの組み合わせは「ｅｄｉｔ（ａ）＊ｅｄｉｔ（ａ）」、「ｅｄｉｔ（ａ）＊ｄｅｌ（ａ）」、「ｎｅｗ（ａ）＊ｄｅｌ（ａ）」、「ｄｅｌ（ａ）＊ｅｄｉｔ（ａ）」、「ｄｅｌ（ａ）＊ｎｅｗ（ａ）」の５通りである。
【００４３】
図７に「ｅｄｉｔ（ａ）＊ｅｄｉｔ（ａ）」パッチ積がマージ可能な場合と競合を起こす場合の例を示す。パッチＰ１、Ｐ２はそれぞれｅｄｉｔ（ａ）パッチであり、それぞれｈｕｎｋ（α、β）、ｈｕｎｋ（γ、δ）を編集するものとする。ここで図７（ａ）によると、ｈｕｎｋ（α、β）とｈｕｎｋ（γ、δ）が重ならない場合、すなわち、β＜γ又はδ＜αの場合、それぞれのパッチが編集する領域は重ならないので、マージ可能である。逆に図７（ｂ）によると、これが成りたたない場合（すなわち、γ≦βかつα≦δである場合）、それぞれのパッチが編集する領域が重なるので競合を起こす。
【００４４】
その他に競合を起こす例として、「ｅｄｉｔ（ａ）＊ｄｅｌ（ａ）」、「ｎｅｗ（ａ）＊ｄｅｌ（ａ）」、「ｄｅｌ（ａ）＊ｅｄｉｔ（ａ）」、「ｄｅｌ（ａ）＊ｎｅｗ（ａ）」の４通りがある。「ｅｄｉｔ（ａ）＊ｄｅｌ（ａ）」では、ｅｄｉｔ（ａ）パッチによる編集がｄｅｌ（ａ）パッチによって無効になるので、競合となる。「ｎｅｗ（ａ）＊ｄｅｌ（ａ）」では、ｎｅｗ（ａ）によって作成したファイルａがｄｅｌ（ａ）によって削除されてしまうため、競合となる。「ｄｅｌ（ａ）＊ｅｄｉｔ（ａ）」では、ｄｅｌ（ａ）で削除したファイルａをｅｄｉｔ（ａ）で編集することはできないので、競合となる。「ｄｅｌ（ａ）＊ｎｅｗ（ａ）」では、ｄｅｌ（ａ）で削除したファイルａをｎｅｗ（ａ）で作成し直すことになり、競合を引き起こす。
【００４５】
２つのパッチ間に依存関係が発生するのは、ｎｅｗ（ａ）とそれに続くｅｄｉｔ（ａ）の組み合わせである。図８に依存関係の例を示す。ｅｄｉｔ（ａ）パッチを適用するためには、これに先立ってｎｅｗ（ａ）パッチが適用され、ファイルａが作成されていなければならない。このため、ｅｄｉｔ（ａ）パッチであるパッチＢ及びパッチＥはｎｅｗ（ａ）パッチであるパッチＡに依存する。
【００４６】
マージ処理は、あるファイルへ適用するパッチを同じファイルで別のパッチが適用された後に適用するために変形する処理である。図９は、パッチのマージ処理の例を示す。図９によると、パッチＡ、Ｂはそれぞれ同じファイルａに適用されるパッチである。ここで、パッチＡをパッチＢが当たった後に適用する（すなわち、マージする）ためには、パッチＡを変形しなければならない。なぜなら、ファイルａの中身はパッチＢの適用によって変化しているため、事前に変化分のオフセット変換を行わなければならないからである。以後の説明では、ファイルａへパッチＢが当たった後のファイルの状態をコンテキストと呼び、パッチＢが当たる前の状態と区別する。
【００４７】
図１０に、パッチＡをコンテキストに適用する場合の具体的なマージ処理を示す。パッチＢではｈｕｎｋ（γ、δ）を編集しているので、パッチＢの適用後、ファイルａはｈｕｎｋ（γ、δ）の範囲分、すなわち、（δ−γ＋１）行分前又は後ろにずれる。つまり、パッチＢがｈｕｎｋ（γ、δ）を挿入するパッチであった場合、ファイルａのγ行目以降は後ろにずれる。逆に、パッチＢがｈｕｎｋ（γ、δ）を削除するパッチであった場合、ファイルａのδ＋１行目以降は前にずれる。このずれをｏｆｆｓｅｔ（ｈｕｎｋ（γ、δ））で表す。ｏｆｆｓｅｔを使うと、パッチＡをマージのために変形したパッチＡ’は、ｈｕｎｋ（α＋ｏｆｆｓｅｔ（ｈｕｎｋ（γ、δ））、β＋ｏｆｆｓｅｔ（ｈｕｎｋ（γ、δ）））を編集することになる。マージ処理はこのオフセット変換を行う処理である。
【００４８】
分散ロック部２０は、全てのクライアント６０ｐ〜６０ｔへのマージ処理を排他的に行うために、マージ処理中のパッチのコミットおよびチェックアウト処理を全てのクライアント６０ｐ〜６０ｔ上のリポジトリ４０で禁止するための手段である。
【００４９】
なお、パッチ管理装置３０は、ユーザインタフェース５０を実現する装置と同一又は別のコンピュータを基本ハードウェアとして用いることもできる。そして、パッチ再構成部１０及びリポジトリ４０は、上記のコンピュータに搭載されたプロセッサにプログラムを実行させることにより実現することもできる。
【００５０】
パッチ管理装置３０は、上記のプログラムをコンピュータに予めインストールすることで実現されても良いし、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯなど）、半導体メモリなどのリムーバブルな記憶媒体に記録し、あるいはＬＡＮやインターネット等のネットワークを介して上記のプログラムを配布し、このプログラムをコンピュータに適宜インストールすることによって実現してもよい。
【００５１】
パッチ記憶装置４１は、上記のコンピュータに内蔵されたメモリやハードディスク装置等の記憶デバイス、上記のコンピュータに外付けされたメモリやハードディスク装置などの記憶デバイス、さらにはフレキシブルディスク等のリムーバブルな記憶媒体などを適宜利用して実現することができる。
【００５２】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼動しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が本実施の形態を実現するための各処理の一部を実行するようにしても良い。記憶媒体は１つに限らず、複数の媒体から本実施の形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【００５３】
上記のコンピュータは、記憶媒体に記憶されたプログラムに基づき、第１の実施の形態における各処理を実行するものであって、パーソナル・コンピュータ等の１つからなる装置、複数の装置がネットワーク接続されたコンピュータ等の何れの構成であっても良い。上記のコンピュータは、パーソナル・コンピュータに限らず、情報処理機器に含まれる演算処理装置、マイクロコンピュータ等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【００５４】
次に、図１１のシーケンス図を参照して、本実施形態に係るパッチ管理装置の動作について詳細に説明する。ここでは、ネットワーク７０を介して互いに通信可能なクライアント６０ｐ〜６０ｔのうち、一例として、クライアント６０ｐにおいて生成（又はクライアント６０ｐに対して入力）されたパッチを、他のクライアント６０ｑ〜６０ｔのリポジトリ４０に反映させる場合を想定する。クライアント６０ｐに備えたパッチ管理装置３０は、バッチジョブとして一定の周期で、又は、ユーザインタフェース５０からの指示に応じて、図１１に示す処理を起動する。
【００５５】
ユーザインタフェース５０は、ネットワーク７０に接続された全てのクライアント６０ｐ〜６０ｔのリポジトリ４０に対する変更点となるパッチ集合を作成し、パッチ管理装置３０へ全体マージ処理を要求する。パッチ集合は、パッチ正規化部１１への入力として渡され、例えば、図５及び図６において示した正規化が施される（ステップＳ１１）。
【００５６】
パッチ管理装置３０は、全体マージ処理全体を安全に行うために、分散ロック部２０を通じて、全てのクライアント６０ｐ〜６０ｔのリポジトリ４０をロックする（ステップＳ１２、Ｓ２１）。ロック中は、リポジトリ４０からのチェックアウトおよびコミット処理は禁止される。
【００５７】
パッチ管理装置３０は、正規化済みパッチ集合を他の全クライアント６０ｑ〜６０ｔへ同報通信する（ステップＳ１３）。同報通信先の各クライアント６０ｑ〜６０ｔでは、同報通信されたパッチ集合を受信する（ステップＳ２２）。
【００５８】
同報通信先の各クライアント６０ｑ〜６０ｔのパッチ演算部１４は、ステップＳ２２において受信したパッチ集合のうちリポジトリ４０へとマージ可能なパッチ集合（マージ可能パッチ）を算出する（ステップＳ２３）。各クライアント６０ｑ〜６０ｔは、ステップＳ２３において求めたマージ可能パッチを同報通信元のクライアント６０ｐの共通パッチ生成部１３へと返信する（ステップＳ２４）。クライアント６０ｐのパッチ管理装置３０に備えた共通パッチ生成部１３は、他のクライアント６０ｑ〜６０ｔから送信されたマージ可能パッチを収集する（ステップＳ１４）。
【００５９】
パッチ管理装置３０では、マージ可能パッチを収集した後、共通パッチ生成部１３が全てのクライアント６０に共通してマージ可能なパッチの集合（「共通パッチ」）を求める（ステップＳ１５）。パッチ管理装置３０は、ステップＳ１５において求められた共通パッチをパッチ同報部１２を通じて他の全てのクライアント６０ｑ〜６０ｔへ同報通信を行う（ステップＳ１６）。同報通信先の各クライアント６０ｑ〜６０ｔでは、同報通信された共通パッチを受信する（ステップＳ２５）。
【００６０】
全てのクライアント６０ｐ〜６０ｔ上のパッチ管理装置３０では、ステップＳ１５において求められた共通パッチをリポジトリ４０へマージするために、パッチ演算部１４を通じてマージ処理を行う（ステップＳ１７、Ｓ２６）。また、全てのクライアント６０ｐ〜６０ｔ上のパッチ管理装置３０は、リポジトリ操作部４２を介して、ステップＳ１７およびＳ２６において変換された共通パッチをリポジトリ４０へコミットする（ステップＳ１８、Ｓ２７）。
【００６１】
パッチ管理装置３０では、分散ロック部２０を通じて分散ロックを解除する（ステップＳ１９、Ｓ２８）。コミットが完了した後、全てのクライアント６０ｐ〜６０ｔは図１１に示す処理を終了する。
【実施例１】
【００６２】
次に、本発明の第１の実施例を、図面を参照して説明する。本実施例は、入力装置としてキーボードを、データ処理装置としてパーソナル・コンピュータを、データ記憶装置として磁気ディスク装置を、出力装置としてディスプレイを備えている。
【００６３】
パーソナル・コンピュータは、リポジトリ操作部４２、分散ロック部２０、パッチ正規化部１１、パッチ同報部１２、共通パッチ生成部１３、パッチ演算部１４、ユーザインタフェース５０として機能する中央演算処理装置を有している。また、パッチ記憶装置４１として機能する磁気ディスク装置を備えている。
【００６４】
ここで、ユーザインタフェース５０から図１２に示されるＡからＨまでのパッチ集合がパッチ再構成部１０へ渡され、全体マージ要求が出されたとする。以後、この全体マージ要求を出したクライアント（一例として、６０ｐ）をマスターサイトと呼ぶ。また、全体マージに参加する他のクライアント（一例として、６０ｑ、６０ｒ）をサイトＸ、サイトＹと呼ぶ。全体マージ実行前の時点で、各サイトのリポジトリ４０にコミットされたパッチの状態を図１３とする。パッチ集合はユーザインタフェース５０からパッチ正規化部１１へと渡される。
【００６５】
パッチ正規化部１１は、与えられたパッチを正規化する。ここでは、図１２に示されるパッチのうちＥが「ｎｅｗ（ｄ）」、Ｈが「ｄｅｌ（ｄ）」となっており、これらのパッチとその間に挟まれるパッチＦ「ｅｄｉｔ（ｄ）」を削除してもパッチ全体としての作用は変わらない。よって、パッチ正規化部１１はこれらのパッチを入力のパッチ集合から除去する。正規化されたパッチ集合は図１４に示されるようになる。
【００６６】
パッチ正規化部１１は、分散ロック部２０を通じて全体マージに参加する全サイトのリポジトリ４０をロックする。ロックが完了すると、正規化済みパッチ集合をパッチ同報部１２を通じてサイトＸ、Ｙへと同報通信する。
【００６７】
サイトＸ、Ｙは、パッチ演算部１４を介して、同報通信された正規化済みパッチ集合を取得し、ローカルのパッチと競合を起こすファイルをパッチ演算で求める。サイトＸにおけるパッチ演算を図１５に示す。まず、全体マージされたパッチ集合内での依存関係を求める。パッチＣは「ｎｅｗ（ｃ）」であり、ファイルｃを新たに生成するパッチである。パッチＤは「ｅｄｉｔ（ｃ）」であり、ファイルｃを編集するパッチである。このとき、依存関係の定義よると、パッチＤはパッチＣに依存する。
【００６８】
次に、サイトＸのパッチ集合との競合関係を求める。競合関係の定義より、競合するパッチはファイルｃを削除するパッチＸＥと、ファイルｃを生成するパッチＣである。ここで、パッチＤはパッチＣに依存するので、さらにパッチＤもパッチＸＥと競合する。また、同じ「ｅｄｉｔ（ａ）」であるパッチＸＤとパッチＢ、Ｇは競合する可能性があるが、ここでは、図７に示される競合判定によって競合しないものと判定されたとする。以上のパッチ演算より、サイトＸのパッチ集合と競合しないパッチ集合は［Ａ、Ｂ、Ｇ］となる。
【００６９】
サイトＹにおけるパッチ演算を図１６に示す。競合する可能性のあるパッチの組合せとして、同じ「ｅｄｉｔ（ｂ）」であるパッチＹＣとパッチＡがある。ここで、図７に示される競合判定によりこれらが競合すると判定されたとする。この場合、サイトＹのパッチ集合と競合しないパッチ集合（すなわち、マージ可能パッチ）は［Ｂ、Ｃ、Ｄ、Ｇ］となる。
【００７０】
サイトＸおよびサイトＹは競合を起こさないパッチ集合をパッチ演算後、パッチ演算部１４を通じてマスターサイトへ返信する。
【００７１】
マスターサイトは、競合を起こさないパッチ集合をサイトＸおよびサイトＹから共通パッチ生成部１３を通じて収集する。収集が完了後、共通パッチ生成部１３はそれぞれのパッチ集合の積集合（「共通パッチ」）を求める。例えば、この例ではサイトＸにおいて競合を起こさないパッチ集合は［Ａ、Ｂ、Ｇ］であり、サイトＹにおいて競合を起こさないパッチ集合は［Ｂ、Ｃ、Ｄ、Ｇ］であるから、共通パッチは［Ｂ、Ｇ］となる。
【００７２】
求められた共通パッチはパッチ同報部１２を通じてサイトＸ、Ｙへ同報通信される。送付先のサイトＸ、Ｙではそれぞれ、マージ処理が行われる。例として、図１７にサイトＸでのマージ処理を示す。共通パッチ［Ｂ、Ｇ］をサイトＸのコンテキストにマージするために、図１０に示されるパッチの変形処理を行う。
【００７３】
変形された共通パッチは、サイトＸのリポジトリ操作部４２を通じてサイトＸのリポジトリ４０にコミットされ、マージが完了する。
【００７４】
図１８に示すように、サイトＸ、Ｙでのマージ処理と同様に、共通パッチはマスターサイトのパッチ演算部１４へと渡され、リポジトリ４０中のパッチ集合とマージのためのパッチ演算による変換が行われる。その後、リポジトリ操作部４２を通じてパッチ記憶装置４１へコミットされる。
【００７５】
コミット完了後、パッチ演算部１４は分散ロックを解除し、パッチ集合の全体へのマージが完了する。
【００７６】
以上、第１の実施形態及び第１の実施例では、ファイルへパッチを適用する前後の差分をｈｕｎｋと呼ばれる行単位の差分で示したが、ＸＭＬや構文木など適切に差分の定義が可能な構造化されたデータ形式によっても、パッチ演算処理を定義し全体へマージすることができる。
【００７７】
また、リポジトリ４０は、コミットされたパッチを保持するためのパッチ記憶装置４１と、パッチ記憶装置４１へパッチをコミットまたはチェックアウトするためのリポジトリ操作部４２から構成されていたが、リポジトリ操作部４２はリポジトリ４０の外にあっても良い。
【００７８】
また、ユーザインタフェース５０がコミットするパッチ集合がすでに正規化されており、パッチ演算部１４が直接処理可能な場合には、パッチ正規化部１１は正規化処理を行わず、パッチ集合を直接パッチ同報部１２への入力として渡しても良い。
【実施例２】
【００７９】
本発明の第２の実施例について図面を参照して説明する。図１９は本発明の第２の実施例に係るパッチ管理装置を備えたクライアントの構成を示すブロック図である。
【００８０】
パッチ管理装置３０は、ネットワークを介して互いに通信可能な複数のクライアント６０ｐ〜６０ｔのそれぞれのリポジトリ４０に対するパッチを管理する。パッチ管理装置３０は、共通パッチ生成部１３及びパッチ演算部１４を備える。共通パッチ生成部１３は、クライアント６０ｐ〜６０ｔそれぞれのリポジトリ４０のいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する。パッチ演算部１４は、共通パッチをリポジトリ４０に格納されたデータにマージする。
【００８１】
本実施例に係るパッチ管理装置によって、ネットワークを介して互いに通信可能な複数のクライアントの間で、パッチ間の競合及び個々のクライアントにおけるパッチのマージ作業を回避しつつ、パッチを当てることができる。
【００８２】
以上の記載は実施例に基づいて行ったが、本発明は、上記実施例に限定されるものではない。
【産業上の利用可能性】
【００８３】
本発明のパッチ管理装置は、ファイルの編集を複数人数で並行に行うバージョン管理システムに対して適用することができる。
【図面の簡単な説明】
【００８４】
【図１】本発明の実施形態に係るパッチ管理装置を備えたクライアントの構成を示すブロック図である。
【図２】ネットワークを介して互いに通信可能な複数のクライアントの間におけるパッチ管理を説明するための図である。
【図３】ファイルを編集するパッチｅｄｉｔ（）の概念図である。
【図４】パッチ集合の構成を示す図である。
【図５】パッチの正規化処理を説明するための図である。
【図６】パッチの正規化処理の説明するための図である。
【図７】パッチの競合判定処理の説明をするための図である。
【図８】パッチの依存関係を示す図である。
【図９】パッチのマージ処理の例を示す図である。
【図１０】パッチのマージ処理のための変形処理を示す図である。
【図１１】本発明の実施形態の全体の動作を示すシーケンス図である。
【図１２】全体へマージするパッチ集合の一例を示す図である。
【図１３】リポジトリにコミットされたパッチ集合の一例を示す図である。
【図１４】正規化処理を行ったパッチ集合の一例を示す図である。
【図１５】パッチの競合判定の一例を示す図である。
【図１６】パッチの競合判定の一例を示す図である。
【図１７】パッチのマージ処理の一例を示す図である。
【図１８】パッチのマージ処理の一例を示す図である。
【図１９】本発明の第２の実施例に係るパッチ管理装置を備えたクライアントの構成を示すブロック図である。
【符号の説明】
【００８５】
１０ パッチ再構成部
１１ パッチ正規化部
１２ パッチ同報部
１３ 共通パッチ生成部
１４ パッチ演算部
２０ 分散ロック部
３０ パッチ管理装置
４０ リポジトリ
４１ パッチ記憶装置
４２ リポジトリ操作部
５０ ユーザインタフェース
６０、６０ｐ〜６０ｔ クライアント
７０ ネットワーク
【特許請求の範囲】
【請求項１】
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理するパッチ管理装置であって、
前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出するように構成された共通パッチ生成部と、
前記共通パッチを前記リポジトリに格納されたデータにマージするように構成されたパッチ演算部と、を備えることを特徴とするパッチ管理装置。
【請求項２】
前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するように構成されたパッチ抽出部を備え、
前記共通パッチ生成部は、前記マージ可能パッチを参照し、その共通部分を共通パッチとして抽出するように構成されたことを特徴とする、請求項１に記載のパッチ管理装置。
【請求項３】
パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化部を備え、
前記パッチ抽出部は、前記パッチ正規化部によって分解されたパッチの積を参照し、前記マージ可能パッチを抽出するように構成されたことを特徴とする、請求項２に記載のパッチ管理装置。
【請求項４】
前記リポジトリのすべてに対する操作をロックするとともに、操作のロックを解除するように構成された分散ロック部を備えることを特徴とする、請求項１ないし３のいずれか一に記載のパッチ管理装置。
【請求項５】
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理するパッチ管理方法であって、
（ａ）前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する共通パッチ生成工程と、
（ｂ）前記共通パッチを前記リポジトリに格納されたデータにマージするパッチ演算工程と、を含むことを特徴とするパッチ管理方法。
【請求項６】
（ｃ）前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するパッチ抽出工程を含み、
前記共通パッチ生成工程（ａ）において、前記マージ可能パッチの共通部分を共通パッチとして抽出することを特徴とする、請求項５に記載のパッチ管理方法。
【請求項７】
（ｄ）パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化工程を含み、
前記パッチ抽出工程（ｃ）において、前記パッチ正規化工程（ｄ）において分解されたパッチの積に基づいて前記マージ可能パッチを抽出することを特徴とする、請求項６に記載のパッチ管理方法。
【請求項８】
前記リポジトリのすべてに対する操作をロックする工程と、
そのロックを解除する工程と、をそれぞれ最初と最後に含む、請求項５ないし７のいずれか一に記載のパッチ管理方法。
【請求項９】
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理する処理をコンピュータに実行させるパッチ管理プログラムであって、
（ａ）前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する共通パッチ生成処理と、
（ｂ）前記共通パッチを前記リポジトリに格納されたデータにマージするパッチ演算処理と、をコンピュータに実行させることを特徴とするパッチ管理プログラム。
【請求項１０】
（ｃ）前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するパッチ抽出処理をコンピュータに実行させ、
前記共通パッチ生成処理（ａ）において、前記マージ可能パッチの共通部分を共通パッチとして抽出する処理をコンピュータに実行させることを特徴とする、請求項９に記載のパッチ管理プログラム。
【請求項１１】
（ｄ）パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化処理をコンピュータに実行させ、
前記パッチ抽出処理（ｃ）において、前記パッチ正規化処理（ｄ）において分解されたパッチの積に基づいて前記マージ可能パッチを抽出する処理をコンピュータに実行させることを特徴とする、請求項１０に記載のパッチ管理プログラム。
【請求項１２】
前記リポジトリのすべてに対する操作をロックする処理と、
そのロックを解除する処理と、をそれぞれ最初と最後にコンピュータに実行させることを特徴とする、請求項９ないし１１のいずれか一に記載のパッチ管理プログラム。
【請求項１】
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理するパッチ管理装置であって、
前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出するように構成された共通パッチ生成部と、
前記共通パッチを前記リポジトリに格納されたデータにマージするように構成されたパッチ演算部と、を備えることを特徴とするパッチ管理装置。
【請求項２】
前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するように構成されたパッチ抽出部を備え、
前記共通パッチ生成部は、前記マージ可能パッチを参照し、その共通部分を共通パッチとして抽出するように構成されたことを特徴とする、請求項１に記載のパッチ管理装置。
【請求項３】
パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化部を備え、
前記パッチ抽出部は、前記パッチ正規化部によって分解されたパッチの積を参照し、前記マージ可能パッチを抽出するように構成されたことを特徴とする、請求項２に記載のパッチ管理装置。
【請求項４】
前記リポジトリのすべてに対する操作をロックするとともに、操作のロックを解除するように構成された分散ロック部を備えることを特徴とする、請求項１ないし３のいずれか一に記載のパッチ管理装置。
【請求項５】
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理するパッチ管理方法であって、
（ａ）前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する共通パッチ生成工程と、
（ｂ）前記共通パッチを前記リポジトリに格納されたデータにマージするパッチ演算工程と、を含むことを特徴とするパッチ管理方法。
【請求項６】
（ｃ）前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するパッチ抽出工程を含み、
前記共通パッチ生成工程（ａ）において、前記マージ可能パッチの共通部分を共通パッチとして抽出することを特徴とする、請求項５に記載のパッチ管理方法。
【請求項７】
（ｄ）パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化工程を含み、
前記パッチ抽出工程（ｃ）において、前記パッチ正規化工程（ｄ）において分解されたパッチの積に基づいて前記マージ可能パッチを抽出することを特徴とする、請求項６に記載のパッチ管理方法。
【請求項８】
前記リポジトリのすべてに対する操作をロックする工程と、
そのロックを解除する工程と、をそれぞれ最初と最後に含む、請求項５ないし７のいずれか一に記載のパッチ管理方法。
【請求項９】
ネットワークを介して互いに通信可能な複数のクライアントのそれぞれのリポジトリに対するパッチを管理する処理をコンピュータに実行させるパッチ管理プログラムであって、
（ａ）前記リポジトリのいずれにおいてもマージすることのできるパッチを共通パッチとして抽出する共通パッチ生成処理と、
（ｂ）前記共通パッチを前記リポジトリに格納されたデータにマージするパッチ演算処理と、をコンピュータに実行させることを特徴とするパッチ管理プログラム。
【請求項１０】
（ｃ）前記リポジトリのそれぞれにおいてマージすることのできるパッチをマージ可能パッチとして抽出するパッチ抽出処理をコンピュータに実行させ、
前記共通パッチ生成処理（ａ）において、前記マージ可能パッチの共通部分を共通パッチとして抽出する処理をコンピュータに実行させることを特徴とする、請求項９に記載のパッチ管理プログラム。
【請求項１１】
（ｄ）パッチをより基本的なパッチの積に分解するように構成されたパッチ正規化処理をコンピュータに実行させ、
前記パッチ抽出処理（ｃ）において、前記パッチ正規化処理（ｄ）において分解されたパッチの積に基づいて前記マージ可能パッチを抽出する処理をコンピュータに実行させることを特徴とする、請求項１０に記載のパッチ管理プログラム。
【請求項１２】
前記リポジトリのすべてに対する操作をロックする処理と、
そのロックを解除する処理と、をそれぞれ最初と最後にコンピュータに実行させることを特徴とする、請求項９ないし１１のいずれか一に記載のパッチ管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２００９−１４６２００（Ｐ２００９−１４６２００Ａ）
【公開日】平成２１年７月２日（２００９．７．２）
【国際特許分類】
【出願番号】特願２００７−３２３５２３（Ｐ２００７−３２３５２３）
【出願日】平成１９年１２月１４日（２００７．１２．１４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２１年７月２日（２００９．７．２）
【国際特許分類】
【出願日】平成１９年１２月１４日（２００７．１２．１４）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]