(57)【要約】【課題】複数人が同一ファイルに対して編集を行った場合に、ファイルの更新履歴および編集内容に基づいて、各編集内容を適切に反映できるリポジトリシステムを提供する。【解決手段】リポジトリサーバ１は、ファイルを格納してバージョン管理を行うファイルデータベース１ｃと、ファイルの読み書きに関する履歴情報を管理するログ管理部１ｄと、クライアント端末２２からファイル書込要求があった場合、書込処理を行うファイルが複数のクライアント端末で同一の元のファイルに対して編集されたファイルの一つであり、他のクライアント端末２１で同一の元のファイルに対して編集されたファイルが既にファイルデータベース１ｃに格納されておれば、要求元のクライアント端末２２に対してファイルのバージョン管理の方法を複数提示する判断処理部１ｅとを備える。【選択図】図１
2009289081.tif 000002
【特許請求の範囲】
【請求項１】
ファイルを格納したリポジトリサーバと、リポジトリサーバから読み出した元のファイルに対して編集を行う複数のクライアント端末とをネットワークを介して互いに接続して、リポジトリサーバは、クライアント端末からファイルの読出要求があった場合に要求元のクライアント端末へファイルを送信する読出処理、クライアント端末からファイルの書込要求があった場合にクライアント端末から送信されたファイルを格納する書込処理を行うリポジトリシステムであって、
ファイルは、当該ファイル本体のデータである主データブロックと、当該ファイル本体以外のデータである副データブロックとを含み、
リポジトリサーバは、
ファイルを格納するとともに各ファイルのバージョン管理を行うデータベースと、
クライアント端末によるファイルの読み書きに関する履歴情報を管理するログ管理部と、
クライアント端末からファイルの書込要求があった場合、書込処理を行うファイルの主データブロックが元のファイルから変更されておれば、書込処理を行うファイルのバージョンを更新してデータベースに格納すると判断し、書込処理を行うファイルの副データブロックのみが元のファイルから変更されておれば、書込処理を行うファイルのバージョンを更新することなく、元のファイルの副データブロックを更新してデータベースに格納すると判断し、さらに書込処理を行うファイルが複数のクライアント端末で同一の元のファイルに対して編集されたファイルの一つであり、他のクライアント端末で同一の元のファイルに対して編集されたファイルが既にデータベースに格納されておれば、要求元のクライアント端末に対してファイルのバージョン管理の方法を複数提示する判断処理部とを備える
ことを特徴とするリポジトリシステム。
【請求項２】
前記クライアント端末は、前記リポジトリサーバから読み出したファイルを表示するとともに当該ファイルを編集する表示・編集部と、前記リポジトリサーバから複数提示されたファイルのバージョン管理の方法を表示するとともに、いずれかのバージョン管理の方法をユーザに選択させて、当該選択結果をリポジトリサーバに送信する選択操作部とを備え、リポジトリサーバのデータベースは、前記選択結果に基づいてファイルのバージョン管理を行い、ファイルを格納することを特徴とする請求項１記載のリポジトリシステム。
【請求項３】
前記判断処理部は、前記クライアント端末からファイルの書込要求があり、書込処理を行うファイルが複数のクライアント端末で同一の元のファイルに対して編集されたファイルの一つであり、他のクライアント端末で同一の元のファイルに対して編集されたファイルが既にデータベースに格納されており、さらに書込要求元のクライアント端末と他のクライアント端末のうち、一方が主データブロックを編集し、他方が副データブロックを編集している場合、他のクライアント端末が編集したファイルに書込要求元のクライアント端末が編集した内容を反映させたファイルをデータベースに格納する、または元のファイルに書込要求元のクライアント端末が編集した内容を反映させたファイルをデータベースに格納する、ことをファイルのバージョン管理の方法として書込要求元のクライアント端末に提示することを特徴とする請求項１または２記載のリポジトリシステム。
【請求項４】
前記判断処理部は、前記クライアント端末からファイルの書込要求があり、書込処理を行うファイルが複数のクライアント端末で同一の元のファイルの主データに対して編集されたファイルの一つであり、他のクライアント端末で同一の元のファイルの主データに対して編集されたファイルが既にデータベースに格納されている場合、書込要求元のクライアント端末が編集したファイルを、他のクライアント端末が編集したファイルと別のバージョンでデータベースに格納する、または他のクライアント端末が編集したファイルを書込要求元のクライアント端末で再編集し、当該再編集したファイルをデータベースに格納する、ことをファイルのバージョン管理の方法として書込要求元のクライアント端末に提示することを特徴とする請求項１乃至３いずれか記載のリポジトリシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リポジトリシステムに関するものである。
【背景技術】
【０００２】
リポジトリシステムは、ファイルを格納しているリポジトリサーバと、リポジトリサーバにネットワークを介して接続して、リポジトリサーバからファイルを取得し、取得したファイルに対して編集を行った後に再びリポジトリサーバにファイルを書き込むクライアント端末とで構成され、リポジトリサーバは、クライアント端末で編集されて再び格納されるファイルのバージョン管理を行っている。
【０００３】
リポジトリサーバに格納されるファイルは複数のブロックから構成され、当該ファイル本体のデータである主データブロックと、当該ファイル本体以外のデータである副データブロックとを含んでおり、具体的には、ファイルを編集するためにクライアント端末に搭載されたアプリケーションが扱う主データブロックと、検索キーワード等のようにリポジトリサーバを利用する際のサポート機能のために作成され、アプリケーションにとって主データブロックより重要度の低い副データブロックと、ファイルのバージョンや記録ログ等のようにリポジトリサーバにおけるファイル管理で使用する管理データブロックとで構成される。主データブロックおよび管理データブロックは１ファイルにつき１つ含まれ、副データブロックは、１ファイルにつき１つ以上含まれる。
【０００４】
そして、リポジトリサーバによるファイルのバージョン管理は、主データブロックに対して行われ、主データブロックに変更があった場合、当該ファイルのバージョン（リビジョン番号）が更新される。副データブロックに変更があった場合は、当該ファイルのリビジョン番号は更新されず、変更前と同一リビジョン番号のファイルに対して上書きが行われる。（例えば、特許文献１参照）。
【特許文献１】特開平８−１０６４１２号公報（段落番号［０１００］〜［０１２６］）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、複数人が同一ファイルに対して編集を行うと、リポジトリサーバへのファイル書き込み時に衝突が発生し、各クライアント端末で編集した内容が、意図しない形でファイルに反映されて、リポジトリサーバに格納されてしまう。
【０００６】
例えば、２人が同一ファイルに対して編集を行った場合、双方が主データブロックに対して編集を行い、リポジトリサーバにファイルを書き込むと、夫々の編集内容が別々に反映された２つの新しいリビジョン番号のファイルが生成される。したがって、双方の編集内容を互いに反映させたい場合には、意図しないファイルが生成されてしまうことになる。
【０００７】
また、２人が同一ファイルに対して編集を行った場合、一方が主データブロックに対して編集を行い、他方が副データブロックに対して編集を行い、双方がリポジトリサーバにファイルを書き込むと、主データブロックが変更された新しいリビジョン番号のファイルと、副データブロックが変更された以前のリビジョン番号のファイルとが生成される。したがって、双方の編集内容を互いに反映させたい場合には、意図しないファイルが生成されてしまうことになる。
【０００８】
さらに、２人が同一ファイルに対して編集を行った場合、双方が副データブロックに対して編集を行い、リポジトリサーバにファイルを書き込むと、後から書き込まれたファイルの編集内容のみが最終的なファイルに反映され、先に書き込みを行ったファイルの編集内容は消失してしまう。
【０００９】
本発明は、上記事由に鑑みてなされたものであり、その目的は、複数人が同一ファイルに対して編集を行った場合に、ファイルの更新履歴および編集内容に基づいて、各編集内容を適切に反映できるリポジトリシステムを提供することにある。
【課題を解決するための手段】
【００１０】
請求項１の発明は、ファイルを格納したリポジトリサーバと、リポジトリサーバから読み出した元のファイルに対して編集を行う複数のクライアント端末とをネットワークを介して互いに接続して、リポジトリサーバは、クライアント端末からファイルの読出要求があった場合に要求元のクライアント端末へファイルを送信する読出処理、クライアント端末からファイルの書込要求があった場合にクライアント端末から送信されたファイルを格納する書込処理を行うリポジトリシステムであって、ファイルは、当該ファイル本体のデータである主データブロックと、当該ファイル本体以外のデータである副データブロックとを含み、リポジトリサーバは、ファイルを格納するとともに各ファイルのバージョン管理を行うデータベースと、クライアント端末によるファイルの読み書きに関する履歴情報を管理するログ管理部と、クライアント端末からファイルの書込要求があった場合、書込処理を行うファイルの主データブロックが元のファイルから変更されておれば、書込処理を行うファイルのバージョンを更新してデータベースに格納すると判断し、書込処理を行うファイルの副データブロックのみが元のファイルから変更されておれば、書込処理を行うファイルのバージョンを更新することなく、元のファイルの副データブロックを更新してデータベースに格納すると判断し、さらに書込処理を行うファイルが複数のクライアント端末で同一の元のファイルに対して編集されたファイルの一つであり、他のクライアント端末で同一の元のファイルに対して編集されたファイルが既にデータベースに格納されておれば、要求元のクライアント端末に対してファイルのバージョン管理の方法を複数提示する判断処理部とを備えることを特徴とする。
【００１１】
この発明によれば、複数のクライアント端末で同一の元のファイルに対して編集を行うと、リポジトリサーバの判断処理部が、書込要求元のクライアント端末に対して、ファイルの更新履歴および編集内容に応じたファイルのバージョン管理の方法を複数提示することによって、同一の元のファイルに対する変更内容を単に上書きして一方の変更内容のみを残すのではなく、複数のクライアント端末による各変更内容をどのように反映させるかをユーザの判断に委ねており、複数のユーザによる変更内容をユーザの意思によって新しいファイルに反映させることができる。すなわち、複数人が同一ファイルに対して編集を行った場合に、ファイルの更新履歴および編集内容に基づいて、各編集内容を適切に反映できる。
【００１２】
請求項２の発明は、請求項１において、前記クライアント端末は、前記リポジトリサーバから読み出したファイルを表示するとともに当該ファイルを編集する表示・編集部と、前記リポジトリサーバから複数提示されたファイルのバージョン管理の方法を表示するとともに、いずれかのバージョン管理の方法をユーザに選択させて、当該選択結果をリポジトリサーバに送信する選択操作部とを備え、リポジトリサーバのデータベースは、前記選択結果に基づいてファイルのバージョン管理を行い、ファイルを格納することを特徴とする。
【００１３】
この発明によれば、複数人が同一ファイルに対して編集を行った場合に、ファイルの更新履歴および編集内容に基づいて、各編集内容を適切に反映できる。
【００１４】
請求項３の発明は、請求項１または２において、前記判断処理部は、前記クライアント端末からファイルの書込要求があり、書込処理を行うファイルが複数のクライアント端末で同一の元のファイルに対して編集されたファイルの一つであり、他のクライアント端末で同一の元のファイルに対して編集されたファイルが既にデータベースに格納されており、さらに書込要求元のクライアント端末と他のクライアント端末のうち、一方が主データブロックを編集し、他方が副データブロックを編集している場合、他のクライアント端末が編集したファイルに書込要求元のクライアント端末が編集した内容を反映させたファイルをデータベースに格納する、または元のファイルに書込要求元のクライアント端末が編集した内容を反映させたファイルをデータベースに格納する、ことをファイルのバージョン管理の方法として書込要求元のクライアント端末に提示することを特徴とする。
【００１５】
この発明によれば、複数のクライアント端末が元のファイルに対して変更を施したデータブロックが衝突しない場合において、複数のクライアント端末による各変更内容をどのように反映させるかをユーザの判断に委ねており、複数のユーザによる変更内容をユーザの意思によって新しいファイルに反映させることができる。
【００１６】
請求項４の発明は、請求項１乃至３いずれかにおいて、前記判断処理部は、前記クライアント端末からファイルの書込要求があり、書込処理を行うファイルが複数のクライアント端末で同一の元のファイルの主データに対して編集されたファイルの一つであり、他のクライアント端末で同一の元のファイルの主データに対して編集されたファイルが既にデータベースに格納されている場合、書込要求元のクライアント端末が編集したファイルを、他のクライアント端末が編集したファイルと別のバージョンでデータベースに格納する、または他のクライアント端末が編集したファイルを書込要求元のクライアント端末で再編集し、当該再編集したファイルをデータベースに格納する、ことをファイルのバージョン管理の方法として書込要求元のクライアント端末に提示することを特徴とする。
【００１７】
この発明によれば、複数のクライアント端末が元のファイルに対して変更を施したデータブロックが衝突する場合において、複数のクライアント端末による各変更内容をどのように反映させるかをユーザの判断に委ねており、複数のユーザによる変更内容をユーザの意思によって新しいファイルに反映させることができる。
【発明の効果】
【００１８】
以上説明したように、本発明では、複数人が同一ファイルに対して編集を行った場合に、ファイルの更新履歴および編集内容に基づいて、各編集内容を適切に反映できるという効果がある。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施の形態を図面に基づいて説明する。
【００２０】
（実施形態）
図１は、本実施形態のリポジトリシステムの構成を示し、リポジトリサーバ１と、複数のクライアント端末２（図１では、２台のクライアント端末２１，２２を示す）とがネットワークＮＴ１を介して互いに接続している。
【００２１】
リポジトリサーバ１は、ネットワークＮＴ１との間で情報授受を行うインターフェース機能を有したネットワークインターフェース部１ａと、クライアント端末２からファイル読出要求、ファイル書込要求等の各要求を受け付けて処理するアクセス要求処理部１ｂと、ファイルを格納するとともに各ファイルのバージョン管理を行うファイルデータベース１ｃと、クライアント端末２によるファイルの読み書きに関する履歴情報（読出時刻、書込時刻、読出ユーザ、書込ユーザ等）を管理するログ管理部１ｄと、クライアント端末２からファイル書込要求があった場合に、ファイルの編集内容とログ管理部１ｄの履歴情報とに基づいて、各ファイルのバージョン管理の方法を判断する判断処理部１ｅと、リポジトリサーバ１にアクセスするクライアント端末２の管理を行うユーザ管理部１ｆとを備える。
【００２２】
クライアント端末２は、ネットワークＮＴ１との間で情報授受を行うインターフェース機能を有したネットワークインターフェース部２ａと、リポジトリサーバ１から読み出したファイルをユーザに対して表示したり、ファイルの編集手段を提供する表示・編集部２ｂと、リポジトリサーバ１からの指示によって、ユーザにファイルの適切な保存処理方法を選択させる選択操作部２ｃとを備える。
【００２３】
そして、クライアント端末２は、リポジトリサーバ１に対して所望のファイルを読み出すためのファイル読出要求を送信し、ファイル読出要求を受信したリポジトリサーバ１では、アクセス要求処理部１ｂが要求されたファイルをファイルデータベース１ｃから取り出し、要求元のクライアント端末２へ送信する。ファイルを受け取ったクライアント端末２では、表示・編集部２ｂがファイルをユーザに表示し、ユーザは表示されたファイルに対して編集を行って内容を変更した後に、変更後のファイルをファイル書込要求とともにリポジトリサーバ１に送信する。ファイル書込要求を受信したリポジトリサーバ１では、アクセス要求処理部１ｂが受け取ったファイルを判断処理部１ｅへ引き渡し、判断処理部１ｅは、ファイルの編集内容とログ管理部１ｄの履歴情報とに基づいてファイルのバージョン管理の方法を判断する。ファイルデータベース１ｃは、変更後のファイルを格納するとともに判断処理部１ｅの判断結果に基づいてファイルのバージョン管理を行う。さらに、ログ管理部１ｄは、ファイルデータベース１ｃからファイルを読み出した時刻、ファイルデータベース１ｃへファイルを書き込んだ時刻、ファイルを読み出したクライアント端末２の情報、ファイルを書き込んだクライアント端末２の情報を履歴情報として保持しておく。
【００２４】
ここで、ファイルは、当該ファイル本体のデータである主データブロックと、当該ファイル本体以外のデータである副データブロックとを含んで、具体的には図２に示す構造を有しており、主データブロックＤ１、副データブロックＤ２、管理データＤ３で構成されている。主データブロックＤ１は、ファイルを編集するためにクライアント端末２に搭載されたアプリケーションが扱うデータ（例えば、文書作成アプリケーションであれば、文書データ本体）であり、副データブロックＤ２は、クライアント端末２のアプリケーションがファイルを扱う際に補助的なデータ（例えば、文書データを検索するときの分類データや検索キーワード等）であり、アプリケーションにとって主データブロックより重要度が低く、管理データＤ３は、リポジトリサーバ１がファイルを管理するために使用するデータ（例えば、ファイルの作成者や更新日時等）である。また、主データＤ１と管理データＤ３は、１ファイルにつき各１つ含まれ、副データブロックＤ２は、１ファイルにつき１つ以上含まれる。
【００２５】
図３は、リポジトリサーバ１によるファイルのバージョン管理の概要を示しており（なお、本実施形態では、リビジョン番号を用いたバージョン管理について例示する）、横軸に時間、縦軸にファイルのリビジョン番号をとり、原点が元のファイルＦを示す。そして、元のファイルＦの主データブロックＤ１を変更したファイルＦａがファイル書込要求とともにクライアント端末２からリポジトリサーバ１に送信されると、リポジトリサーバ１では、アクセス要求処理部１ｂがファイルＦａを判断処理部１ｅへ引き渡し、判断処理部１ｅは、元のファイルＦと受け取ったファイルＦａとを比較して変更箇所を検索する。この場合、主データブロックＤ１が変更されているので、判断処理部１ｅは、変更後のファイルＦａのリビジョン番号を更新すると判断し、データベース１ｃは、リビジョン番号を更新したファイルＦａを格納する。
【００２６】
また、元のファイルＦの副データブロックＤ２のみを変更したファイルＦｂがファイル書込要求とともにクライアント端末２からリポジトリサーバ１に送信されると、リポジトリサーバ１では、アクセス要求処理部１ｂがファイルＦｂを判断処理部１ｅへ引き渡し、判断処理部１ｅは、元のファイルＦと受け取ったファイルＦｂとを比較して変更箇所を検索する。この場合、副データブロックＤ２のみが変更されているので、判断処理部１ｅは、変更後のファイルＦｂのリビジョン番号を更新しないと判断し、ファイルデータベース１ｃは、ファイルＦの副データブロックＤ２を更新したファイルＦｂを、リビジョン番号を更新することなく格納する。
【００２７】
さらに、元のファイルＦの主データブロックＤ１と副データブロックＤ２の両方を変更した場合は、上述の主データブロックＤ１の変更に対する判断を優先する。
【００２８】
なお、管理データＤ３は、クライアント端末２での書き換えは許可されておらず、リポジトリサーバ１のファイルデータベース１ｃが、変更後のファイルに対して管理データ３の内容を書き換える。
【００２９】
このように、元のファイルＦ１のどのデータブロックに変更があるかによってバージョン管理方式が異なっており、副データブロックＤ２の編集に伴ってリビジョン番号が更新されないことで、主データブロックＤ１が編集されていないにも関わらずリビジョン番号の異なるファイルが生成されることを防止している。
【００３０】
上記図３では、元のファイルを１つのクライアント端末２のみが変更した場合のバージョン管理について説明したが、次に、同一リビジョン番号の同一ファイルに対して複数のクライアント端末２が変更を施した後に書き込みを行う場合のバージョン管理について説明する。
【００３１】
図４に示すように、クライアント端末２１，２２が、同一リビジョン番号の同一のファイルＦ０（元のファイル）をリポジトリサーバ１から読み込んで編集を行い、クライアント端末２１が先に変更後のファイルＦ１をリポジトリサーバ１へ書き込んだ場合、クライアント端末２２が変更後のファイルＦ２をリポジトリサーバ１へ書き込もうとすると、クライアント端末２１によるファイルＦ１の変更内容とクライアント端末２２によるファイルＦ２の変更内容とが衝突してしまう（図４中のＡ点）。そこで、リポジトリサーバ１の判断処理部１ｅは、ログ管理部１ｄを参照して、ファイルＦ１ａとファイルＦ２ｂとが、同一リビジョン番号の同一ファイルＦ０に対して編集を施されたファイルであることを認識すると、各シチュエーションに応じた複数の対応パターン情報をクライアント端末２２に送信し、クライアント端末２２は、対応パターン情報をファイル表示・編集部２ｂに表示し、ユーザは、表示された複数の対応パターンから、いずれかの対応パターンを選択する。各シチュエーションにおける対応パターンを以下に示す。
【００３２】
［シチュエーション１：クライアント端末２１が元のファイルＦ０に対して主データブロックＤ１を編集したファイルＦ１ａを作成し、クライアント端末２２が元のファイルＦ０に対して副データブロックＤ２を編集したファイルＦ２ｂを生成した場合］
クライアント端末２２がファイルＦ２ｂをリポジトリサーバ１に送信した時点で、リポジトリサーバ１のデータベース１ｃには、元のファイルＦ０からリビジョン番号が更新されたファイルＦ１ａが既に書き込まれており、シチュエーション１での対応パターンは、図５に示すように、
（１１）クライアント端末２２による副データブロックＤ２の変更内容をデータベース１ｃ内のファイルＦ１ａの副データブロックＤ２に反映させたファイルＦ３を新たに生成して、リビジョン番号を更新することなくデータベース１ｃに格納する。
（１２）クライアント端末２２による副データブロックＤ２の変更内容をデータベース１ｃ内のファイルＦ０の副データブロックＤ２に反映させたファイルＦ２ｂを、リビジョン番号を更新することなくデータベース１ｃに格納する。
（１３）ファイルＦ２ｂを破棄する。
の３パターンとなる。
【００３３】
［シチュエーション２：クライアント端末２１が元のファイルＦ０に対して副データブロックＤ２を編集したファイルＦ１ｂを作成し、クライアント端末２２が元のファイルＦ０に対して主データブロックＤ１を編集したファイルＦ２ａを生成した場合］
クライアント端末２２がファイルＦ２ａをリポジトリサーバ１に送信した時点で、リポジトリサーバ１のデータベース１ｃには、元のファイルＦ０の副データブロックＤ２を更新したファイルＦ１ｂが既に書き込まれており、シチュエーション２での対応パターンは、図６に示すように、
（２１）クライアント端末２２によるファイルＦ２ａの主データブロックＤ１の変更内容をデータベース１ｃ内のファイルＦ１ｂの主データブロックＤ１に反映させたファイルＦ３を新たに生成し、リビジョン番号を更新してデータベース１ｃに格納する。
（２２）クライアント端末２２による主データブロックＤ１の変更内容をデータベース１ｃ内のファイルＦ０の主データブロックＤ１に反映させたファイルＦ２ａを、リビジョン番号を更新してデータベース１ｃに格納する。
（２３）ファイルＦ２ａを破棄する。
の３パターンとなる。なお図６中において、ファイルＦ２ｂとファイルＦ３とは、説明のために異なるリビジョン番号としているが、実際は同一のリビジョン番号となる場合もあり得る。
【００３４】
［シチュエーション３：クライアント端末２１が元のファイルＦ０に対して主データブロックＤ１を編集したファイルＦ１ａを作成し、クライアント端末２２も元のファイルＦ０に対して主データブロックＤ１を編集したファイルＦ２ａを生成した場合］
クライアント端末２２がファイルＦ２ａをリポジトリサーバ１に送信した時点で、リポジトリサーバ１のデータベース１ｃには、元のファイルＦ０からリビジョン番号が更新されたファイルＦ１ａが既に書き込まれており、シチュエーション３での対応パターンは、図７に示すように、
（３１）クライアント端末２２においてファイルＦ１ａの変更内容を確認した後、ファイルＦ１ａに対する編集をやり直した新たなファイルＦ３を作成し、ファイルＦ１ａのリビジョン番号を更新したファイルＦ３としてデータベース１ｃに書き込む。
（３２）クライアント端末２２による主データブロックＤ１の変更内容をデータベース１ｃ内のファイルＦ０の主データブロックＤ１に反映させたファイルＦ２ａを、リビジョン番号を更新して、ファイルＦ１ａとは異なるブランチでデータベース１ｃに格納する。
（３３）ファイルＦ２ａを破棄する。
の３パターンとなる。なお図７中において、上述の（３１），（３２）のファイルＦ２ａとファイルＦ３とは、説明のために異なるリビジョン番号としているが、実際は同一のリビジョン番号となる場合もあり得る。
【００３５】
［シチュエーション４：クライアント端末２１が元のファイルＦ０に対して副データブロックＤ２を編集したファイルＦ１ｂを作成し、クライアント端末２２も元のファイルＦ０に対して副データブロックＤ２を編集したファイルＦ２ｂを生成し、且つクライアント端末２１，２２が各々編集した副データブロックＤ２が、複数の副データブロックのうち同一データブロックである場合］
クライアント端末２２がファイルＦ２ｂをリポジトリサーバ１に送信した時点で、リポジトリサーバ１のデータベース１ｃには、元のファイルＦ０の副データブロックＤ２を更新したファイルＦ１ｂが既に書き込まれており、シチュエーション４での対応パターンは、図８に示すように、
（４１）ファイルＦ１ｂの副データブロックＤ２をクライアント端末２２の編集内容に更新したファイルＦ２ｂをデータベース１ｃに格納し、ファイルＦ１ｂの変更内容を破棄する。
（４２）クライアント端末２２においてファイルＦ１ｂの変更内容を確認した後、ファイルＦ１ｂに対する編集をやり直した新たなファイルＦ３を作成してデータベース１ｃに書き込む。
（４３）ファイルＦ２ｂを破棄する。
の３パターンとなる。なお図８中において、上述の（４１），（４２）のファイルＦ２ｂとファイルＦ３とは、説明のために異なるリビジョン番号としているが、実際は同一のリビジョン番号となる。
【００３６】
上記シチュエーション１，２は、クライアント端末２１，２２が元のファイルＦ０に対して変更したデータブロックが重複しない（衝突しない）場合であり、上記シチュエーション３は、クライアント端末２１，２２が元のファイルＦ０に対して変更を施した主データブロックＤ１が重複する（衝突する）場合であり、上記シチュエーション４は、クライアント端末２１，２２が元のファイルＦ０に対して変更を施した副データブロックＤ２が重複する（衝突する）場合である。
【００３７】
上記シチュエーション１〜４をまとめると、リポジトリサーバ１の判断処理部１ｅは、まず主データブロックＤ１の衝突があるか否かを判断し、主データブロックＤ１の衝突があれば、上記シチュエーション３と同様の対応パターン情報をクライアント端末２２に送信し、主データブロックＤ１の衝突がなければ、次に副データブロックの衝突があるか否かを判断する。そして、副データブロックＤ２の衝突があれば、上記シチュエーション４と同様の対応パターン情報をクライアント端末２２に送信し、主データブロックＤ１、副データブロックＤ２ともにデータブロックの衝突がなければ、上記シチュエーション１または２と同様の対応パターン情報をクライアント端末２２に送信する。この処理は、クライアント端末２１，２２が、元のファイルＦ０の主データブロックＤ１と副データブロックＤ２の両方を編集した場合でも同様に行われる。
【００３８】
すなわち、リポジトリサーバ１の判断処理部１ｅは、ログ管理部１ｄを参照して、ファイルＦ１ａとファイルＦ２ｂとが、同一リビジョン番号の同一ファイルＦ０に対して編集を施されたファイルであることを認識すると、上記シチュエーション１〜４に応じた複数の対応パターン情報（１１）〜（１３）または（２１）〜（２３）または（３１）〜（３３）または（４１）〜（４３）を、クライアント端末２１による変更内容とともにクライアント端末２２に送信して、対応パターン情報の選択操作画面をファイル表示・編集部２ｂに表示するよう選択操作部２ｃに要求する。
【００３９】
そして、クライアント端末２２の選択操作部２ｃは、上記対応パターン情報、およびクライアント端末２１による変更内容をファイル表示・編集部２ｂに表示し、ユーザは、クライアント端末２１による変更内容を参照して、表示された複数の対応パターンから、いずれかの対応パターンを選択する。
【００４０】
そして、ユーザが、クライアント端末２２の選択操作部２ｃを操作していずれかの対応パターンを選択すると、選択結果がリポジトリサーバ１へ送信され、リポジトリサーバ１では、判断処理部１ｅが選択された対応パターンに基づいてファイルのバージョン管理方法を判断し、ファイルデータベース１ｃが、ファイルのバージョン管理を行ってファイルを格納する。
【００４１】
また、対応パターンとして上記（３１）（４２）が選択されて、クライアント端末２１によって編集されたファイルＦ１ａまたはＦ１ｂに対してクライアント端末２２が再編集を行う場合は、クライアント端末２２は、当該ファイルＦ１ａまたはＦ１ｂをリポジトリサーバ１からダウンロードして再編集を行い、再編集後の新たなファイルＦ３をリポジトリサーバ１へ送信する。
【００４２】
このように、本実施形態のリポジトリシステムでは、クライアント端末２１，２２で同一の元のファイルＦ０に対して編集を行うと、リポジトリサーバ１の判断処理部１ｅがファイルのデータブロック毎に変更の有無をチェックし、書込要求元のクライアント端末２２に対して、ファイルの更新履歴および編集内容に応じたファイルのバージョン管理の方法を複数提示することによって、同一の元のファイルＦ０に対する変更内容を単に上書きして一方の変更内容のみを残すのではなく、クライアント端末２１，２２による各変更内容をどのように反映させるかをユーザの判断に委ねており、複数のユーザによる変更内容をユーザの意思によって新しいファイルに反映させることができる。すなわち、クライアント端末２１，２２が同一ファイルに対して編集を行った場合に、ファイルの更新履歴および編集内容に基づいて、各編集内容を適切に反映できるのである。
【００４３】
例えば、クライアント端末２１，２２による同一の元のファイルＦ０への編集があった場合に、元のファイルＦ０に対して変更を施したデータブロックが衝突しなければ（上記シチュエーション１，２参照）、クライアント端末２１，２２での編集内容を両方とも反映することができる。また、クライアント端末２１，２２が元のファイルＦ０に対して変更を施したデータブロックに衝突がある場合でも（上記シチュエーション３，４参照）、書込要求元のクライアント端末２２で再編集を行うことによって、クライアント端末２１，２２での編集内容を両方とも反映することができる。
【００４４】
図９は、上記シチュエーション１〜４におけるリポジトリサーバ１の判断処理部１ｅでの処理をまとめたフローチャートである。なお、説明のため、元のファイルＦ０に対して、クライアント端末２１が編集を施したファイルをファイルＦ１（上記Ｆ１ａ，Ｆ１ｂを含む）と称し、クライアント端末２２が編集を施したファイルをファイルＦ２（上記Ｆ２ａ，Ｆ２ｂを含む）と称す。
【００４５】
まず、判断処理部１ｅは、クライアント端末２２から受信した編集後のファイルＦ２の主データブロックＤ１が元のファイルＦ０から変更されているか否かを判断し（ステップＳ１）、主データブロックが変更されておれば、他のクライアント端末（ここでは、クライアント端末２１）から元のファイルＦ０の主データブロックＤ１に編集を施したファイルＦ１が既にリポジトリサーバ１に格納されているか否かを判断する（ステップＳ２）。クライアント端末２１から主データブロックＤ１に編集を施したファイルＦ１が格納されていなければ、次にクライアント端末２１からファイルＦ０の副データブロックＤ２に編集を施したファイルＦ１が既にリポジトリサーバ１に格納されているか否かを判断し（ステップＳ３）、クライアント端末２１から副データブロックＤ２に編集を施したファイルＦ１が格納されていなければ、クライアント端末２２から受信した編集後のファイルＦ２の内容を変更することなくリビジョン番号を更新すると判断し、データベース１ｃは、元のファイルＦ０からリビジョン番号を更新したファイルＦ２を格納して（ステップＳ４）、判断処理部１ｅでの処理を完了する。
【００４６】
次に、ステップＳ２において、判断処理部１ｅは、クライアント端末２１から主データブロックＤ１に編集を施したファイルＦ１が既にリポジトリサーバ１に格納されておれば、クライアント端末２１，２２の各変更内容が衝突すると判断して、クライアント端末２２に対して上記シチュエーション３の対応パターン（３１），（３２），（３３）を、クライアント端末２１による変更内容とともに送信し、対応パターン情報の選択操作画面をファイル表示・編集部２ｂに表示するよう選択操作部２ｃに要求する。そして、クライアント端末２２の選択操作部２ｃは、上記対応パターン情報、およびクライアント端末２１による変更内容をファイル表示・編集部２ｂに表示し、ユーザは、クライアント端末２１による変更内容を参照して、表示された複数の対応パターン（３１），（３２），（３３）から、いずれかの対応パターンを選択する。そして、ユーザが、クライアント端末２２の選択操作部２ｃを操作していずれかの対応パターンを選択すると、選択結果がリポジトリサーバ１へ送信される（ステップＳ５）。
【００４７】
リポジトリサーバ１の判断処理部１ｅは、クライアント端末２２から選択結果を受け取ると、対応パターン（３２）［クライアント端末２２による主データブロックＤ１の変更内容をデータベース１ｃ内のファイルＦ０の主データブロックＤ１に反映させたファイルＦ２を、リビジョン番号を更新して、ファイルＦ１とは異なるブランチでデータベース１ｃに格納する。］が選択されたか否かを判断し（ステップＳ６）、対応パターン（３２）が選択されていなければ、対応パターン（３１）［クライアント端末２２においてファイルＦ１の変更内容を確認した後、ファイルＦ１に対する編集をやり直した新たなファイルＦ３を作成し、ファイルＦ１のリビジョン番号を更新したファイルとしてデータベース１ｃに書き込む。］を選択したとして、判断処理部１ｅでの処理を終了する。または対応パターン（３３）［ファイルＦ２を破棄する］を選択しておれば、ファイルＦ２を破棄して判断処理部１ｅでの処理を終了する（ステップＳ７）。
【００４８】
一方、ステップＳ６において対応パターン（３２）が選択された場合、クライアント端末２１から元のファイルＦ０の副データブロックＤ２に編集を施したファイルＦ１が既にリポジトリサーバ１に格納されているか否かを判断し（ステップＳ３）、クライアント端末２１から副データブロックＤ２に編集を施したファイルＦ１が格納されていなければ、ステップＳ４において、対応パターン（３２）の処理を行う。
【００４９】
また、ステップＳ３において、クライアント端末２１から副データブロックＤ２に編集を施したファイルＦ１が格納されておれば、クライアント端末２２に対して上記シチュエーション２の対応パターン情報（２１），（２２），（２３）を、クライアント端末２１による変更内容とともに送信し、対応パターン情報の選択操作画面をファイル表示・編集部２ｂに表示するよう選択操作部２ｃに要求する。そして、クライアント端末２２の選択操作部２ｃは、上記対応パターン情報、およびクライアント端末２１による変更内容をファイル表示・編集部２ｂに表示し、ユーザは、クライアント端末２１による変更内容を参照して、表示された複数の対応パターン（２１），（２２），（２３）から、いずれかの対応パターンを選択する。そして、ユーザが、クライアント端末２２の選択操作部２ｃを操作していずれかの対応パターンを選択すると、選択結果がリポジトリサーバ１へ送信される（ステップＳ８）。
【００５０】
リポジトリサーバ１の判断処理部１ｅは、クライアント端末２２から選択結果を受け取ると、対応パターン（２３）［ファイルＦ２を破棄する］が選択されておればファイルＦ２を破棄して処理を完了するが、対応パターン（２３）が選択されていなければ、クライアント端末２２から受信した編集後のファイルＦ２の副データブロックＤ２が元のファイルＦ０から変更されているか否かを判断し（ステップＳ９）、ファイルＦ２に副データブロックＤ２の変更がなければ、ファイルＦ２（ステップＳ２のＹｅｓ分岐経由、Ｎｏ分岐経由ともに）を、ファイルＦ１のリビジョン番号を更新したファイルとし、この新リビジョンのファイルにクライアント端末２１による副データブロックＤ２の変更内容を反映するか否かを判断する（すなわち、ステップＳ８において対応パターン（２１）が選択されたか否かを判断する）（ステップＳ１０）。ステップＳ８において対応パターン（２２）が選択されていた場合には、上記ステップＳ４において、クライアント端末２２による主データブロックＤ１の変更内容をデータベース１ｃ内のファイルＦ０の主データブロックＤ１に反映させたファイルＦ２を、リビジョン番号を更新してデータベース１ｃに格納する処理を行い、ステップＳ８において対応パターン（２１）が選択されていた場合には、クライアント端末２１による副データブロックＤ２の変更内容をファイルＦ２に反映する差分更新を行って、新リビジョンのファイルを生成し（クライアント端末２２によるファイルＦ２の主データブロックＤ１の変更内容をデータベース１ｃ内のファイルＦ１の主データブロックＤ１に反映させたファイルＦ３を新たに生成し、リビジョン番号を更新してデータベース１ｃに格納することに相当する）（ステップＳ１１）、判断処理部１ｅでの処理を完了する。なお、ステップＳ８でのユーザ判断（対応パターン（２１）または（２２）の選択）が影響するのはステップＳ１０においてである。
【００５１】
また、ステップＳ９においてファイルＦ２に副データブロックＤ２の変更があれば、ファイルＦ１で変更した副データブロックＤ２とファイルＦ２で変更した副データブロックＤ２とが、同一のデータブロックであって衝突があるか否かを判断し（副データブロックＤ２は、１ファイルにつき１つ以上含まれるため、必ずしも衝突が発生するとは限らない）（ステップＳ１２）、衝突がなければ上記ステップＳ１０の処理を行い、衝突があれば、クライアント端末２２に対してファイルの再編集の提案を、クライアント端末２１による変更内容とともに送信し、ファイルの再編集をクライアント端末２２のユーザに促して、判断処理部１ｅでの処理を終了する。またはファイルＦ２を破棄して判断処理部１ｅでの処理を終了する（ステップＳ１３）。
【００５２】
次に、判断処理部１ｅは、ステップＳ１において、クライアント端末２２から受信した編集後のファイルＦ２の主データブロックＤ１が元のファイルＦ０から変更されておらず、副データブロックＤ２が元のファイルＦ０から変更されておれば、クライアント端末２１から元のファイルＦ０の主データブロックＤ１に編集を施したファイルＦ１が既にリポジトリサーバ１に格納されているか否かを判断する（ステップＳ１４）。クライアント端末２１から主データブロックＤ１に編集を施したファイルＦ１が格納されておれば、クライアント端末２２に対して上記シチュエーション１の対応パターン情報（１１），（１２），（１３）を、クライアント端末２１による変更内容とともに送信し、対応パターン情報の選択操作画面をファイル表示・編集部２ｂに表示するよう選択操作部２ｃに要求する。そして、クライアント端末２２の選択操作部２ｃは、上記対応パターン情報、およびクライアント端末２１による変更内容をファイル表示・編集部２ｂに表示し、ユーザは、クライアント端末２１による変更内容を参照して、表示された複数の対応パターン（１１），（１２），（１３）から、いずれかの対応パターンを選択する。そして、ユーザが、クライアント端末２２の選択操作部２ｃを操作していずれかの対応パターンを選択すると、選択結果がリポジトリサーバ１へ送信される（ステップＳ１５）。
【００５３】
リポジトリサーバ１の判断処理部１ｅは、クライアント端末２２から選択結果を受け取ると、対応パターン（１３）［ファイルＦ２を破棄する］が選択されておればファイルＦ２を破棄して処理を完了するが、対応パターン（１３）が選択されていなければ、次に対応パターン（１１）［クライアント端末２２による副データブロックＤ２の変更内容をデータベース１ｃ内のファイルＦ１（元のファイルＦ０からリビジョン番号が更新されている）の副データブロックＤ２に反映させたファイルＦ３を新たに生成して、リビジョン番号を更新することなくデータベース１ｃに格納する。］が選択されたか否かを判断し（ステップＳ１６）、対応パターン（１１）が選択されれば、ファイルＦ２で変更された副データブロックＤ２がファイルＦ１の変更内容と衝突するか否かを判断し（ステップＳ１７）、さらに衝突がなければ、データベース１ｃ内のファイルＦ１の副データブロックＤ２に対して、クライアント端末２２によるファイルＦ２の副データブロックＤ２の変更内容を反映させたファイルＦ３を新たに生成して、判断処理部１ｅでの処理を完了する（ステップＳ１８）。
【００５４】
一方、ステップＳ１７で衝突があれば、クライアント端末２２に対して上記シチュエーション４の対応パターン情報（４１），（４２），（４３）を、クライアント端末２１による変更内容とともに送信し、対応パターン情報の選択操作画面をファイル表示・編集部２ｂに表示するよう選択操作部２ｃに要求する。そして、クライアント端末２２の選択操作部２ｃは、上記対応パターン情報、およびクライアント端末２１による変更内容をファイル表示・編集部２ｂに表示し、ユーザは、クライアント端末２１による変更内容を参照して、表示された複数の対応パターン（４１），（４２），（４３）から、いずれかの対応パターンを選択する。そして、ユーザが、クライアント端末２２の選択操作部２ｃを操作していずれかの対応パターンを選択すると、選択結果がリポジトリサーバ１へ送信される（ステップＳ１９）。
【００５５】
リポジトリサーバ１の判断処理部１ｅは、クライアント端末２２から選択結果を受け取ると、対応パターン（４１）［ファイルＦ１の副データブロックＤ２をクライアント端末２２の編集内容に更新したファイルＦ２をデータベース１ｃに格納し、ファイルＦ１の変更内容を破棄する。］が選択されたか否かを判断し（ステップＳ２０）、対応パターン（４１）が選択されておれば、上記ステップＳ１８の処理を行い、対応パターン（４１）が選択されていなければ、対応パターン（４２）［クライアント端末２２においてファイルＦ１の変更内容を確認した後、ファイルＦ１に対する編集をやり直した新たなファイルＦ３を作成してデータベース１ｃに書き込む。］を選択したとして、判断処理部１ｅでの処理を終了する。または対応パターン（４３）［ファイルＦ２を破棄する］を選択しておれば、ファイルＦ２を破棄して判断処理部１ｅでの処理を終了する（ステップＳ２１）。
【００５６】
次に、ステップＳ１６において、対応パターン（１１）が選択されず、対応パターン（Ｓ１２）が選択された場合は、クライアント端末２１から元のファイルＦ０の副データブロックＤ２に編集を施したファイルＦ１が既にリポジトリサーバ１に格納されているか否かを判断し（ステップＳ２２）、クライアント端末２１から副データブロックＤ２に編集を施したファイルＦ１が格納されていなければ、クライアント端末２２による副データブロックＤ２の変更内容をデータベース１ｃ内のファイルＦ０の副データブロックＤ２に反映させたファイルＦ２を、リビジョン番号を更新することなくデータベース１ｃに格納する（ステップＳ２３）。一方、クライアント端末２１から副データブロックＤ２に編集を施したファイルＦ１が格納されていれば、ファイルＦ１で変更した副データブロックＤ２とファイルＦ２で変更した副データブロックＤ２とが、同一のデータブロックであって衝突があるか否かを判断し（副データブロックＤ２は、１ファイルにつき１つ以上含まれるため、必ずしも衝突が発生するとは限らない）（ステップＳ２４）、衝突がなければ、上記ステップＳ２３の処理を行う。
【００５７】
ステップＳ２４において衝突がある場合には、クライアント端末２２に対して上記シチュエーション４の対応パターン情報（４１），（４２），（４３）を、クライアント端末２１による変更内容とともに送信し、対応パターン情報の選択操作画面をファイル表示・編集部２ｂに表示するよう選択操作部２ｃに要求する。そして、クライアント端末２２の選択操作部２ｃは、上記対応パターン情報、およびクライアント端末２１による変更内容をファイル表示・編集部２ｂに表示し、ユーザは、クライアント端末２１による変更内容を参照して、表示された複数の対応パターン（４１），（４２），（４３）から、いずれかの対応パターンを選択する。そして、ユーザが、クライアント端末２２の選択操作部２ｃを操作していずれかの対応パターンを選択すると、選択結果がリポジトリサーバ１へ送信される（ステップＳ２５）。
【００５８】
リポジトリサーバ１の判断処理部１ｅは、クライアント端末２２から選択結果を受け取ると、対応パターン（４１）［ファイルＦ１の副データブロックＤ２をクライアント端末２２の編集内容に更新したファイルＦ２をデータベース１ｃに格納し、ファイルＦ１の変更内容を破棄する。］が選択されたか否かを判断し（ステップＳ２６）、対応パターン（４１）が選択されておれば、ファイルＦ１（ファイルＦ０とは同一リビジョン番号）の副データブロックＤ２をクライアント端末２２の編集内容に更新したファイルＦ２をデータベース１ｃに格納して、ファイルＦ１の変更内容を破棄し（ステップＳ２３）、対応パターン（４１）が選択されていなければ、上記ステップＳ２１の処理を行って、判断処理部１ｅでの処理を終了する。
【００５９】
また、ステップＳ１４において、クライアント端末２１から主データブロックＤ１に編集を施したファイルＦ１が格納されていなければ、上記ステップＳ２２の処理を行う。
【００６０】
なお、本実施形態では、２台のクライアント端末２１，２２を例示しているが、クライアント端末２は３台以上であっても、上記同様に動作することで、同様の効果を得ることができる。
【図面の簡単な説明】
【００６１】
【図１】実施形態のリポジトリシステムの構成を示す図である。
【図２】同上のファイルのデータ構造を示す図である。
【図３】同上の１台のクライアント端末によるファイル編集を示す図である。
【図４】同上の複数のクライアント端末によるファイル編集を示す図である。
【図５】同上のシチュエーション１におけるファイル編集を示す図である。
【図６】同上のシチュエーション２におけるファイル編集を示す図である。
【図７】同上のシチュエーション３におけるファイル編集を示す図である。
【図８】同上のシチュエーション４におけるファイル編集を示す図である。
【図９】同上の動作フローチャートを示す図である。
【符号の説明】
【００６２】
１  リポジトリサーバ
１ａ  ネットワークインターフェース部
１ｂ  アクセス要求処理部
１ｃ  ファイルデータベース
１ｄ  ログ管理部
１ｅ  判断処理部
１ｆ  ユーザ管理部
２（２１，２２）  クライアント端末
２ａ  ネットワークインターフェース部
２ｂ表示・編集部
２ｃ  選択操作部
ＮＴ１  ネットワーク
【図１】
2009289081.tif 000003
【図２】
2009289081.tif 000004
【図３】
2009289081.tif 000005
【図４】
2009289081.tif 000006
【図５】
2009289081.tif 000007
【図６】
2009289081.tif 000008
【図７】
2009289081.tif 000009
【図８】
2009289081.tif 000010
【図９】
2009289081.tif 000011