JP2000250799A

JP2000250799A - 複製ファイル管理システム

Info

Publication number: JP2000250799A
Application number: JP11053642A
Authority: JP
Inventors: Hideaki Okada; 英明岡田
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1999-03-02
Filing date: 1999-03-02
Publication date: 2000-09-14

Abstract

(57)【要約】【課題】複数のコンピュータシステムに複製される共
有ファイルの内容を一致させたい。【解決手段】ユーザファイル１０１のリポジトリデー
タベース１０２へのチェックイン及びチェックアウトを
行う更新ファイルチェックイン手段１０６と更新ファイ
ルチェックアウト手段１０７を設ける。ユーザファイル
１０１の変更情報を更新情報記録手段１０３によりリポ
ジトリデータベース１０２に登録する。他のコンピュー
タシステムから更新情報送受信手段１０４により更新情
報を受け取り、更新適用、衝突解決手段１０５が、受け
取った更新情報の適用及び衝突解決を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータシス
テム上で保持され、共用されるファイルの複製を管理す
るシステムに関する。

【０００２】

【従来の技術】移動通信ネットワークの普及、小型で安
価な携帯端末の普及により、外出先で報告書などの文書
の作成を行ったり、既に作成していた文書、或いは、作
成途中の文書をオフィスから携帯端末上にコピーして持
ち出して外出先で修正を行う機会が増えている。一方オ
フィスでは情報の共有のため、文書のファイルをファイ
ルサーバ等に集めて、オフィス内の各計算機から参照、
更新できるようになっているが、このように外出先でそ
のような共用ファイルを作成あるいは更新した場合、そ
のファイルをファイルサーバへ書き戻す処理を行うのが
常である。

【０００３】また、インターネットの普及により、地理
的に離れた場所間での協調作業もより一般的になってき
ている。このような固定端末利用時でも、その間を結ぶ
ネットワークが十分な性能を持っていない場合や、ファ
イアウォールの存在によりＮＦＳ（ネットワークファイ
ルシステム）やＦＴＰ（ファイルトランスファプロトコ
ル）等のファイルシステムの共有、或いは、ファイルの
転送が容易にできない場合、１箇所のファイルサーバを
共有することは事実上不可能である。そこで、それぞれ
の場所で独立にファイルを作成、或いは、変更し、作成
あるいは変更の終了後、１箇所にそのファイルを集めた
り、各場所で持つファイルの内容をすべて同一にする必
要がある。

【０００４】このような状況においては、新規作成ファ
イルの場合には単にコピーすればよいが、修正されたフ
ァイルの場合、他者により修正されていないか確認の
後、修正が行われていなければそのままコピーし、修正
されていればその修正を併合しなければならない。

【０００５】このように、複数の計算機上でそれぞれ複
製を保持し、それらを独立に変更することを許す場合、
特開平９−２４４９３６にあるように、それぞれの計算
機において更新の記録を取り、他の計算機での更新の記
録を収集して併合することにより、複製ファイルの一致
化（同期処理）を行う。

【０００６】

【発明が解決しようとする課題】しかし、ユーザがまさ
に文書を編集しているときに、システム管理者やプログ
ラムの定期起動機構等により、他の計算機での変更の記
録の収集とその併合が行われ、ユーザが編集対象として
いる文書ファイルが変更された場合、ユーザがそれに気
付かずに併合後のファイルに対して、併合結果を含んで
いないユーザ自身が編集中の文書を保存してしまうかも
しれない。

【０００７】このような問題に対し、次のような解決策
が考えられる。・編集中はファイルをロックする。・併合後に、その併合されたファイルの読み込みなしに
書き込みが行われた場合、ユーザが併合に気が付いてい
ないと判断して、書き込みを行わせない。しかし、前者の場合、併合処理そのものを行うことがで
きず、また、すべてのアプリケーションがそのように改
変されなければならず、現実的ではない。後者の場合
は、ファイルシステムそのものを改変しなければならな
い。一般にファイルシステムの機能変更は、ＯＳ（オペ
レーティングシステム）カーネルへの変更を意味し、そ
れは容易ではなく、また、ＯＳに依存することになる。

【０００８】また、ユーザが文書の編集途中にその文書
の保存を行ったり、アプリケーションにより、自動的に
任意の時点での文書の保存が行われることがあるが、そ
のような時に他の計算機で、変更の記録の収集とその併
合が行われた場合、編集途中の文書に対するユーザ自身
による変更が、まだ書きかけものであるにもかかわら
ず、収集され、その計算機へ送られ、併合されてしま
う。これは、単に中途半端な内容のものが送られてしま
うというだけではなく、編集途中に機密事項や、機密と
いうほどではなくても複製ファイルを共有している相手
には知られたくない事項を記述してしまい、そのチェッ
クがまだ終わらぬうちに同期処理が行われてしまい、そ
のような相手に知られては困る情報が伝わってしまうと
いう事態を引き起こすこともある。

【０００９】このような問題に対し、同期処理対象とす
るファイルをユーザが指定する、という解決策が考えら
れる。しかし、あるユーザＡが、あるファイルａを編集
して、編集が終了したところで同期処理対象であること
を複製ファイル管理システムに通知したとする。続い
て、別のユーザＢが、そのファイルａの別の部分を、ユ
ーザＡの結果を引き継ぐ形で編集しているとする。既に
で述べたように、この技術は、必ずしも固定的で十分な
接続性を持ったネットワークで接続されているとは限ら
ない場所間の複製ファイルの管理を主要な対象としてい
る。すなわち、ユーザＡの編集終了通知後、直ちに同期
処理が行われるとは限らないし、また、ネットワークが
接続されるのを待って、ユーザＢが編集をはじめるとい
うのも非効率的である。

【００１０】このような、ユーザの複製ファイルに対す
る操作と、他の計算機での変更の記録の収集とその併合
処理とのタイミングによる問題は、特にそのファイルシ
ステムが複数のユーザによりアクセスされるファイルサ
ーバ等で顕著に現れやすい。

【００１１】本発明の目的は、ユーザの複製ファイルに
対する操作と、他の計算機での変更の記録の収集とその
併合処理のタイミングによる問題点を解決した、コンピ
ュータ上で保持され、共用されるファイルの複製を管理
するシステムを提供することである。

【００１２】

【課題を解決するための手段】この発明に係る複製ファ
イル管理システムは、コンピュータシステム上に保持さ
れ、共有されるファイルの複製を管理する複製ファイル
管理システムであって、共用され、複製されるユーザフ
ァイルに対し、その内容と更新内容を記録するリポジト
リデータベースと、リポジトリデータベースへ更新され
たユーザファイルの登録を行う更新ファイルチェックイ
ン手段と、リポジトリデータベースからユーザファイル
の取出しを行う更新ファイルチェックアウト手段と、更
新されたユーザファイルの情報を更新情報としてリポジ
トリデータベースへ記録する更新情報記録手段と、更新
情報記録手段により記録される更新情報を他の複製ファ
イル管理システムと交換する更新情報送受信手段と、交
換により得られた他の複製ファイル管理システムの更新
情報をリポジトリデータベース上のユーザファイルの内
容に適用する、或いは、順序が衝突している更新を解決
する更新適用、衝突解決手段とを備えたことを特徴とす
る。

【００１３】この発明に係る複製ファイル管理システム
の更新情報記録手段は、ユーザファイルがバイナリファ
イルである場合、テキストファイルに変換して、差分を
取り、その差分をリポジトリデータベースへ記録するこ
とを特徴とする。

【００１４】この発明に係る複製ファイル管理システム
の更新情報記録手段は、前回登録されたユーザファイル
の内容と今回登録するユーザファイルの内容との差分を
差分更新情報として記録することを特徴とする。

【００１５】この発明に係る複製ファイル管理システム
の更新情報記録手段は、差分更新情報として、逆適用可
能な差分を使用し、新たな更新情報を記録する場合に、
更新の履歴を管理し、更新適用、衝突解決手段は、その
更新の履歴と差分の逆適用及び順適用により、衝突して
いるファイルの内容を生成することを特徴とする。

【００１６】この発明に係る複製ファイル管理システム
の更新情報記録手段は、新たな更新情報を記録する場合
に、更新の履歴を管理し、更新適用、衝突解決手段は、
自動的に解決できなかった衝突を放置することを許すこ
とを特徴とする。

【００１７】この発明に係る複製ファイル管理システム
の更新適用、衝突解決手段は、更に、衝突を放置したま
ま更新することを許すことを特徴とする。

【００１８】この発明に係る複製ファイル管理システム
は、更に、不要になった更新情報を削除する更新情報削
除手段を備えたことを特徴とする。

【００１９】この発明に係る複製ファイル管理システム
のリポジトリデータベースは、各更新情報をノードとす
る更新履歴管理ツリーを記録し、複製ファイル管理シス
テムは、更に、不要になった更新履歴管理ツリーのノー
ドを削除する更新履歴管理ツリー削除手段を備えたこと
を特徴とする。

【００２０】この発明に係る複製ファイル管理システム
の更新情報送受信手段は、更新情報を送信する際に、圧
縮して送信することを特徴とする。

【００２１】この発明に係る複製ファイル管理システム
の更新情報記録手段は、リポジトリデータベースへの登
録の際に、情報を圧縮して登録することを特徴とする。

【００２２】この発明に係る複製ファイル管理システム
の更新ファイルチェックアウト手段は、更新の衝突を放
置したままユーザファイルの取り出しを行う場合、更新
の優先順位情報に応じて取り出す内容を決定することを
特徴とする。

【００２３】この発明に係る複製ファイル管理システム
の優先順位情報は、ユーザファイルを登録したユーザの
情報を含むことを特徴とする。

【００２４】この発明に係る複製ファイル管理システム
の優先順位情報は、更新量情報を含むことを特徴とす
る。

【００２５】この発明に係る複製ファイル管理システム
の優先順位情報は、登録した時刻であるチェックイン時
刻を含むことを特徴とする。

【００２６】

【発明の実施の形態】実施の形態１．図１に、本複製フ
ァイル管理システムのコンポーネントの構成を示す。本
複製ファイル管理システムは、コンピュータシステムに
備えられているものである。・ユーザファイル１０１は、ユーザがアプリケーション
等を使用することによって参照し、更新するファイルで
ある。・リポジトリデータベース１０２は、ユーザファイル１
０１の内容を記録するユーザファイルに関する管理デー
タベースである。以下、単にリポジトリともいう。・更新ファイルチェックイン手段１０６は、ユーザファ
イル１０１の内容をリポジトリデータベース１０２へ登
録する（チェックインする）。・更新ファイルチェックアウト手段１０７は、リポジト
リデータベース１０２に保存されているユーザファイル
１０１の内容を、ユーザファイル１０１へ取出す（チェ
ックアウトする）。・更新情報記録手段１０３は、更新ファイルチェックイ
ン手段１０６により、ユーザファイル１０１をリポジト
リデータベース１０２へ登録する時に、その更新情報をリポジトリデータベース１０２へ記録する。・
更新情報送受信手段１０４は、この複製ファイル管理シ
ステムで管理され（必ずしもこのシステム上で生成され
たものだけではなく、他のシステム上で生成され、この
システムへ送信されたものも含んでいてよい）、リポジ
トリデータベース１０２に記録されている更新情報を、
複製ファイルを持つ別の複製ファイル管理システムへ送
信し、或いは、逆に複製ファイルを持つ別の複製ファイ
ル管理システムで管理され、記録されている更新情報を
受信し、リポジトリデータベース１０２へ記録する。・
更新適用、衝突解決手段１０５は、更新情報送受信手段
１０４によって他の複製ファイル管理システムから受信
される更新情報が、リポジトリデータベース１０２に記
録されているユーザファイル１０１の内容に対してその
まま適用な可能な場合、適用し、或いは、その更新が衝
突しており、そのままの適用が不可能な場合、衝突を解
決して、結果をリポジトリデータベース１０２へ記録す
る。・ユーザファイル１０１、リポジトリデータベース
１０２は、例えば、コンピュータシステムの固定ディス
クに記憶される。・更新情報記録手段１０３、更新情報
送受信手段１０４、更新適用、衝突解決手段１０５、更
新ファイルチェックイン手段１０６、更新ファイルチェ
ックアウト手段１０７は、例えば、コンピュータシステ
ムのハードウェア又はソフトウェア又はその組み合わせ
で構成される。望ましくは、プログラムモジュールで構
成するのがよい。

【００２７】図１に示すように、更新ファイルチェック
イン手段１０６を用いて、ユーザファイル１０１の内容
をリポジトリデータベース１０２へ登録することをチェ
ックイン、更新ファイルチェックアウト手段１０７を用
いて、リポジトリデータベース１０２に含まれる（別の
複製ファイル管理システムから受信され、適用された更
新内容を含むこともある）ユーザファイル１０１の内容
をユーザファイル１０１として取出すことをチェックア
ウトという。

【００２８】本複製ファイル管理システムを備える別の
コンピュータシステムが存在し、そこにユーザファイル
１０１の複製ファイルが存在する。厳密には、同一のコ
ンピュータシステム上に、複数の本複製ファイル管理シ
ステムが存在してもよい。また、チェックアウトされた
結果のユーザファイルは複数存在してもよい。すなわ
ち、異なるディスク上の空間（ディレクトリ）にチェッ
クアウトされてよい。

【００２９】更新情報送受信手段１０４において、２つ
の複製ファイル管理システムが接続されるが、それは、
ＬＡＮ（ローカルエリアネットワーク）やシリアルケー
ブルにより直接接続されていてもよいし、インターネッ
トのように間に複数のゲートウェイが存在して接続され
ていてもよいし、或いは、携帯電話などの移動無線ネッ
トワークにより、必要なときにのみ接続されるのでもよ
い。また、ＴＣＰ／ＩＰ（トランスミッションコントロ
ールプロトコル／インターネットプロトコル）のような
通信プロトコルを直接用いてもよいし、ファイアウォー
ルの迂回などの理由により電子メールを利用したり、フ
レキシブルディスク等を用いてもよい。

【００３０】図２に、本複製ファイル管理システムの動
作概要を示す。主に右半分はユーザファイルに対する操
作、左半分はリポジトリデータベースに対する操作を示
す。１．複製ファイル管理システムＡのあるコンピュータシ
ステム上で、ユーザは、アプリケーションソフトウェア
を使用し、ユーザファイルを生成する（図中省略）。２．ユーザファイルを複製対象とするために、更新ファ
イルチェックイン手段を用いて、ユーザファイルをリポ
ジトリデータベースへ登録する（２０４）。このとき、
更新情報記録手段により、更新情報もリポジトリデータ
ベースへ登録される（２０１）。すなわち、更新情報
は、既存ファイルへの変更の他に、新規ファイルの組み
込み、すなわち、無から有への変更を含み、更には、有
から無、すなわちファイルの削除をも含んでいてもよ
い。３．このようにして、この複製ファイル管理システムＡ
で記録された更新情報は、何らかのトリガにより、別の
複製ファイル管理システムＢへ送信され、或いは、別の
複製ファイル管理システムＢで記録された更新情報が複
製ファイル管理システムＢから受信される（２０２）。
また、複製ファイル管理システムＡで記録されたユーザ
ファイルも新規ファイルの組み込みとして複製ファイル
管理システムＢへ送信される。４．受信した更新情報に関し、その更新のリポジトリデ
ータベースへの適用を行う（２０３）。今の例の場合、
更新情報を受け取った別の複製ファイル管理システムＢ
では、新しくユーザファイルが追加されたとの更新情報
を適用し、複製ファイル管理システムＢのリポジトリデ
ータベースに新しくファイルを登録する。その別の複製
ファイル管理システムＢでは、更新ファイルチェックア
ウト手段を用いることにより、複製ファイル管理システ
ムＢのリポジトリデータベースよりユーザファイルをチ
ェックアウトできる（２０５）。

【００３１】更に、複製ファイル管理システムＢの存在
するコンピュータシステム上で、１．ユーザファイルの複製を参照しているユーザが、フ
ァイルを更新したとする（２０６）。２．ユーザは、更新したファイルを更新ファイルチェッ
クイン手段を用いて、チェックイン（２０４）すること
により、そのファイルを更新したことを複製ファイル管
理システムＢのリポジトリデータベースへ登録する。３．このとき、更新情報記録手段により更新情報が複製
ファイル管理システムＢのリポジトリデータベースへ記
録される（２０１）。４．何らかのトリガにより、複製ファイル管理システム
Ａと複製ファイル管理システムＢとの間で更新情報交換
（２０２）が行われると、複製ファイル管理システムＡ
では、更新適用（２０３）が行われ、複製ファイル管理
システムＡのリポジトリデータベース上のユーザファイ
ルの内容は複製ファイル管理システムＢのユーザファイ
ルの内容と同じになる。５．複製ファイル管理システムＡのあるコンピュータシ
ステム上のユーザは、更新ファイルチェックアウト手段
を用いてチェックアウト（２０５）を行うことにより、
この複製ファイル管理システムＢのあるコンピュータシ
ステム上で更新された結果のユーザファイルを取出すこ
とができる。

【００３２】また、１．複製ファイル管理システムＡ，Ｂのあるコンピュー
タシステム双方上でユーザファイルの更新（２０６）が
行われ、２．複製ファイル管理システムＡ，Ｂの両者でユーザフ
ァイルがチェックインされて、その内容がそれぞれのリ
ポジトリデータベースへ記録され（２０４）、その更新
情報がそれぞれのリポジトリデータベースに記録され
（２０１）、３．何らかのトリガにより更新情報の交換（２０２）が
両者の間で行われた場合、４．更新適用、衝突解決手段により、衝突している更新
の解決が行われ（２０３）、５．ユーザはチェックアウト（２０５）を行うことによ
り、衝突解決の結果を取出すことができる。これらが、
通常の動作である。

【００３３】更新情報がリポジトリ上のファイルに対し
てそのまま適用可能か、或いは、ローカルの、或いは、
また別の複製ホストからの更新情報と衝突しており、そ
のままは適用可能でないか、どうかは、例えば、Ｐａｒ
ｋｅｒらによる論文ＤｅｔｅｃｔｉｏｎｏｆＭｕｔ
ｕａｌＩｎｃｏｎｓｉｓｔｅｎｃｙｉｎＤｉｓｔ
ｒｉｂｕｔｅｄＳｙｓｔｅｍｓ（ＩＥＥＥＴｒａｎ
ｓａｃｔｉｏｎｓｏｎＳｏｆｔｗａｒｅＥｎｇｉ
ｎｅｅｒｉｎｇ，Ｖｏｌ．ＳＥ−９，Ｎｏ．３，ＭＡＹ
１９８３）に記載されているバージョンベクタ等の機構
を用いることにより管理できる。すなわち、ここでい
う、更新の衝突とは、内容の衝突を意味するのではな
い。上の例では、同期処理により、内容が同一化された
後、それぞれ独立に更新されている。このように、更新
の衝突とは、時間軸上での更新が起こったタイミングの
衝突をいう。

【００３４】ここで、複製ファイル管理システムＡ（以
下、単にＡという）において、更新ファイルのチェック
インが行われ、複製ファイル管理システムＢ（以下、単
にＢという）のあるコンピュータシステム上では、チェ
ックアウトされている複製ファイルをオープンし、まさ
に編集しようとしているとする。ここでＡからの要求に
より更新情報の交換及びその適用が行われた場合、複製
ファイルのリポジトリ上の内容は更新されるが、Ｂ上で
ファイルをオープンし、編集しているユーザが参照して
いるファイルは書き換えられない。もし、リポジトリが
存在しなければ、Ｂ上でユーザが参照しているファイル
が書き換えられてしまい、しかも、ユーザがそれに気付
かずに上書きしてしまうかもしれない。更に、上書き後
に複製の同期処理をＡに対して行った場合、同期処理の
管理を行っているアルゴリズムによっては、Ａにおける
更新内容がまったく失われてしまうかもしれない。すな
わち、一旦、ＡからＢへの更新情報の送信を含む、複製
の同期処理により、内容が一致化されている。その後
で、Ｂにおいて変更が行われ、Ａにおいて変更が行われ
なければ、Ｂにおける変更結果はＡにおける前の変更結
果を含むものだと期待し、すなわち、更新の衝突はな
く、そのままそれがＡへ適用されてしまう。

【００３５】また、マルチユーザ環境のファイルサーバ
上で、この複製ファイル管理システムＡにより管理され
ているユーザファイルが使用されているとする。ある担
当者が、ここまでは送ってよい、と判断されるところま
で編集し、同期対象であることを複製ファイル管理シス
テムに通知したとする。それから続きの別の章の編集作
業を、別の担当者が行うとする。ネットワークの接続性
の問題により、別の章の編集作業中に同期処理が行われ
た場合、やはりリポジトリがなければ、その編集作業中
のものが更新結果として送られてしまう。不完全なもの
が送られることもあれば、編集中に紛れ込み、まだチェ
ックされていない機密事項が送られてしまうかもしれな
い。

【００３６】このようにして、リポジトリデータベース
及び更新ファイルチェックイン手段、更新ファイルチェ
ックアウト手段を追加することにより、ユーザの複製フ
ァイルに対する操作と、他の記録の収集とその併合処理
のタイミングによる問題点を解決できる。

【００３７】ここで、本システムの具体的な実現例につ
いて説明する。リポジトリデータベースには、チェック
インされているファイルの内容及び図３に示すリポジト
リデータベース管理表、図４に示す更新履歴管理表があ
る。

【００３８】図３に示すリポジトリデータベース管理表
について説明する。ディレクトリ名を含むファイル名
が、ｄｉｒｅｃｔｏｒｙＡ／ｆｉｌｅＡであるファイル
に対して、それが最後にチェックインにより、または同
期処理によりリポジトリ内のファイルの内容が更新され
た時刻、それがユーザファイルとしてチェックアウトさ
れた時刻、チェックアウトされたときのサイズ、そのと
きのチェックサム、またファイルに関する属性を持つ。
属性は、一般に、ファイルの作成時刻や、所有者、アク
セス権など、ＯＳやファイルシステムによって異なり、
実際にチェックアウトされたときにそれがそのチェック
アウト先のファイルシステムに適切にマッピングされる
（もちろん、マッピングできない属性もあり得る）。最
終チェックイン時刻、最終チェックアウト時刻、最終チ
ェックアウト時のサイズ、チェックサムは、チェックア
ウト先毎に管理される。図においては、ｄｉｒＡにチェ
ックアウトされた場合を示している。ここで、サイズや
チェックサムは必ずしも必要と言うわけではないが、後
で述べるチェックアウト処理において、更新判定処理の
効率化のために導入している。

【００３９】図４に示す更新履歴管理表について説明す
る。履歴番号は、履歴の識別子である。ファイル名は、
どのファイルについての更新履歴であるかを示す。更新
内容は、新規作成、更新、削除などの更新の内容を示
す。更新内容記録ファイルで、実際にどのような更新で
あったかを記録するファイル名を指し示している。ここ
で更新内容記録ファイルに記録される内容は、もっとも
単純な場合、チェックインされたファイルの内容そのも
のである。また、チェックインされているファイルの内
容そのものを、図に示したｌｏｇ／１のようにパス名と
ファイル名を用いて差し示してもよい。ただし、その場
合、同一ファイルが続いてチェックインされると、最初
の情報（古い履歴）は、更新情報記録の内容としては不
適切であるため、この最初の情報を更新情報記録として
送信しないようにしなければならない。

【００４０】図５にチェックイン時の動作を示す。ま
ず、チェックインが指示されると、それが既にチェック
インされているファイルか否か、リポジトリデータベー
ス管理表を参照することによりチェックする（５０
１）。ここでチェックインされていなければ、新規ファ
イルとしてその内容をリポジトリデータベースへ登録
し、また、更新履歴管理表に新規作成の更新として新し
くエントリを生成する（５０４）。既にチェックインさ
れているファイルの場合、最新の内容がチェックアウト
されているか、リポジトリデータベース管理表の最終チ
ェックイン時刻と最終チェックアウト時刻を比較するこ
とによりチェックする（５０２）。最終チェックイン時
刻は、そのファイルの最近のチェックイン時刻又は同期
処理によりそのファイルの内容が更新された時刻であ
る。もし、最終チェックアウト時刻が最終チェックイン
時刻以降ならば、ユーザは、最新のユーザファイルをチ
ェックアウトして使用していることになる。従って、最
新のユーザファイルを使用しているユーザからチェック
インが指示された場合は、チェックインをそのまま認め
てやればよい。すなわち、最終チェックアウト時刻が最
終チェックイン時刻以降の場合、最新のユーザファイル
を使用しているユーザからのチェックインであると判断
し、ファイルの内容をリポジトリデータベースへ登録
し、更新履歴管理表に既存ファイルの更新として新しく
エントリを作成する（５０３）。逆に、最終チェックア
ウト時刻が最終チェックイン時刻以前ならば、ユーザ
は、古いユーザファイルをチェックアウトして使用して
いたことになる。従って、そのファイルのチェックイン
をそのまま認めてしまうと、最新のユーザファイルが失
われてしまう。そこで、最新の内容がチェックアウトさ
れていなかった場合、ユーザに最新の内容をチェックア
ウトするように指示する（５０５）。或いは、自動的に
チェックアウト処理を行ってもよい。ユーザは、最新の
内容をチェックアウトし、そのチェックアウトした最新
の内容に対して更新を変え、再びそのファイルのチェッ
クインを指示する。この２回目のチェックインの指示の
際は、必ず、最終チェックアウト時刻が最終チェックイ
ン時刻以降となるので、チェックインが認められる（５
０３）。

【００４１】図６に、チェックアウト時の動作を示す。
まず、チェックアウトがユーザから指示されると、最新
のリポジトリの内容がチェックアウトされているか否
か、最終チェックアウト時刻と最終チェックイン時刻を
比較することにより、チェックする（６０１）。最終チ
ェックアウト時刻が最終チェックイン時刻以降の場合、
最新のリポジトリの内容が既にチェックアウトされてい
るので、チェックアウトを指示したユーザに対して何も
しない。もし、最終チェックアウト時刻が最終チェック
イン時刻以前ならば、ユーザが最後にチェックアウトし
てから同期処理が発生し、リポジトリのそのファイルの
内容が更新されてしまい、ユーザが現在使用しているユ
ーザファイルは古いユーザファイルであるということに
なる。このように、最新の内容がチェックアウトされて
いない場合、最後にチェックアウトされたユーザファイ
ルの内容が、その後ユーザにより変更されているかチェ
ックする（６０２）。例えば、まず、ユーザが使用して
いるファイルのファイルサイズがリポジトリデータベー
ス管理表に記録されている最終チェックアウト時のサイ
ズと違っていれば、明らかに更新されているし、サイズ
が同じでも、チェックサムが異なっていれば、明らかに
更新されている。ここでチェックサムは、最近よく用い
られているＭＤ５などの一方向ハッシュ関数でもよい。
さて、最後のチェックアウト以降にファイルの内容が変
更されていなければ、リポジトリの内容をユーザが使用
しているユーザファイルに適用する（６０４）。このリ
ポジトリの内容を適用することにより、ユーザファイル
は最新の内容となる。もし、最後のチェックアウト以降
にファイルの内容がユーザにより変更されていれば、リ
ポジトリの内容と、更新されているファイルの内容とを
マージする（６０３）。すなわち、同期処理により受信
した更新内容と、ユーザが自分で行った更新内容の両方
がユーザファイルに適用されることにより、ユーザファ
イルは最新の内容となる。

【００４２】ここで、６０４の更新されているリポジト
リの内容を、更新されていないユーザファイルへ適用す
る方法は、１０５の更新適用、衝突解決手段における、
更新適用と同様に処理することができる。この例の場
合、単純にファイルのコピー（上書き）を行えばよい。

【００４３】また、６０３の更新されているリポジトリ
の内容と、更新されているユーザファイルとのマージの
方法は、更新衝突解決と同様に処理することができる。
もっともよく知られている方法として、テキストファイ
ルの場合に、ＵＮＩＸ（登録商標）のｄｉｆｆコマンド
による差分抽出の結果を、ｐａｔｃｈコマンドにより、
適用する方法がある。また、アプリケーションによって
は、それ特有のマージ方法がある場合があり、ファイル
名やファイルそのものの内容から、アプリケーションを
特定し、そのアプリケーションに応じた衝突解決（マー
ジ）手段を呼び出すこともよく行われている。

【００４４】実施の形態２．しかし、衝突解決は、必ず
しも自動的に行われる必要はない。衝突している更新情
報の内容によっては、機械的には解決できず、人手を必
要とする場合がある。これは、２０３における更新適
用、衝突解決時の場合も同じである。２０３において、
自動解決に失敗した場合、・ユーザファイルのあるディ
レクトリに違う名前、例えば、ｆｉｌｅＡに対して、ｃ
ｏｎｆｌｉｃｔｅｄ．ｆｉｌｅＡなどの名前で、衝突し
ている内容のファイルを作成する。・電子メールなどの
手段を用いて、ユーザに知らせ、或いは、知らせなくと
も、チェックアウト時に衝突している内容のファイルを
上記同様に作成する。などの手法を取ることができる。
いずれにせよ、６０３での自動解決の失敗を含めて、人
間が修正し、或いは、マージし、チェックインする。

【００４５】更新衝突の自動解決に失敗した場合を考え
る。この場合、ユーザは、自動解決に失敗した更新情報
のマージを手動で行うことになる。しかし、対象ファイ
ルが１００ページにもおよぶ文書ファイルの場合、か
つ、その文書ファイルがアプリケーションに固有のバイ
ナリファイルである場合、両方の文書を見比べて修正を
施していくのは面倒である。このような場合でも、アプ
リケーションによっては、テキストファイルや、より表
現力のあるＨＴＭＬ（ハイパーテキストマークアップラ
ンゲージ）、或いは、ＸＭＬ（エクステンシブマークア
ップランゲージ）などのテキストベースのフォーマット
に変換することが可能である場合がある。このような場
合、更新情報記録手段において、更新情報を記録する際
に、チェックイン前とチェックインしようとするファイ
ルをそれぞれ、前述のアプリケーションの機能を用いて
テキストベースのフォーマットに変換し、それらの差分
を同時に登録しておく。これを自動衝突解決に失敗した
場合に、ヒントとしてユーザに提示することにより、こ
の面倒なマージ作業を容易にすることができる。

【００４６】実施の形態３．更新情報記録手段１０３に
より、記録されるもっとも簡単な形態の更新情報とは、
更新後（現在）のユーザファイル１０１の内容そのもの
であるが、これを前にチェックインされたユーザファイ
ル１０１の内容と現在の内容との差分情報とすることに
より、リポジトリデータベースにより消費される記憶容
量が削減され、また更新情報送受信手段により交される
通信量が削減される。これらは、特に大きいファイルに
対して少量の変更が行われた場合に、有効であり、ま
た、公衆網（電話）を介したネットワーク接続時などの
低速、或いは、高価なネットワーク使用時に有効であ
る。

【００４７】差分情報は、ＵＮＩＸシステムでよく用い
られているｄｉｆｆコマンドのようにテキストファイル
の１行ごとの差を取ったものであったり、またバイナリ
ファイルの場合、バイト単位や複数のバイト単位で構成
されるブロック毎の差であったりする。また、ファイル
名や、ファイル中の識別子によりファイルの種別、特に
アプリケーションの種別が特定できる場合、そのファイ
ルに適した差分抽出方法を用いてもよい。

【００４８】リポジトリデータベースからファイルの内
容を取り出す場合、最新の内容が取り出せれば十分であ
る。従って、通常、その最新の内容をそのまま記録し、
また、差分による更新情報を記録する。しかし、ファイ
ルが作成されたときのファイルの内容をそのまま記録
し、また、差分による更新情報を記録し、ファイルの内
容を取り出す場合には、作成されたときの内容に、順番
に差分を適用して、取り出すべき内容を生成してもよ
い。ただし、この処理は、完全に行われなければなら
ず、通常は、前者の方法でよい。

【００４９】実施の形態４．更新情報として、差分を用
いた場合に自動的な衝突解決に失敗したとする。このと
き、同期処理の相手から送られてくるのは、通常、差分
情報のみである、従って、衝突の内容によっては、同期
処理の相手に存在する、衝突解決の比較対象となるファ
イル全体の内容を得られないことになる。これは、テキ
ストファイルの場合、人手による修正により、十分解決
可能であるため、あまり大きな問題ではないが、バイナ
リファイルの場合、比較してマージしようとしても、比
較対象となるファイルの内容をアプリケーションを介し
て参照することができない、という致命的な問題を引き
起こすことになる。このような場合には、差分情報では
なく、ファイルの内容全体を改めて送信するよう同期処
理相手の複製ファイル管理機構に要求することになる。

【００５０】ここで、更新情報である差分は、かならず
逆方向に適用可能であるものであるように生成するとす
る。すなわち、ファイルの内容からＡからＢに変更され
たときに生成された差分情報をｄとすれば、Ｂとｄから
もとのファイルの内容Ａを生成できるものとする。これ
は既に紹介しているｄｉｆｆとｐａｔｃｈでも、ｐａｔ
ｃｈを逆にあてることにより実現されている。このよう
に差分による更新情報を生成すれば、最新の内容が取り
出せることはこのシステムに不可欠な機能であるのだか
ら、衝突する更新が起こる前まで、差分の逆適用により
戻り、そこから衝突する差分を順適用することにより、
比較対象となるファイルの内容を生成できる。これによ
り、再度ファイルの内容を送信する必要がなくなり、特
にファイルのサイズが大きい場合に、通信量の削減が実
現できる。

【００５１】図７を用いて説明する。ある複製ファイル
管理システムＡに、あるファイルが新規チェックインさ
れたとする。このとき、バージョンＡ−０を生成する。
このファイルは、同期処理により、別の複製ファイル管
理システムＢへ複製され、チェックアウトされる。シス
テムＡでは、ファイルが更新され、チェックインされ
る。このとき、バージョンＡ−１を生成する。一方、シ
ステムＢでもファイルが更新され、チェックインされ
る。このとき、バージョンＢ−１を生成する。このと
き、それぞれで生成される差分に基づく更新情報には、
バージョンＡ−０からＡ−１への差分、バージョンＡ−
０からＢ−１への差分、という情報を含めるようにす
る。システムＡに対して、差分更新情報Ｂ−１が送られ
てきた場合、システムＡでのバージョンＡ−１とは、バ
ージョンＡ−０で同じであったことがわかる。従って、
バージョンＡ−１の内容に対して、差分更新情報Ａ−１
を逆に適用し、バージョンＡ−０の内容を生成し、さら
に、送られてきた差分更新情報Ｂ−１を順に適用するこ
とにより、バージョンＢ−１の内容を生成することがで
きる。このように、更新のツリーを管理するようにする
ことにより、衝突しているファイルの内容を生成するこ
とができる。

【００５２】実施の形態５．自動衝突解決は、特にバイ
ナリファイルの場合、かなり困難であり、人手の介入は
不可避である。しかし、人手の介入ができない場合があ
る。図８に、その例である中間リポジトリを持つ場合の
システム構成を示す。複製ファイル管理システムＡは、
オフィスのファイルサーバ上に構築されており、インタ
ーネット上に複製ファイル管理システムＢが存在する。
ＡとＢの間には、ファイアウォールが存在し、ネットワ
ーク接続はファイアウォールの中からしか、すなわちＡ
からＢの方へしか行うことができないとする。複製ファ
イル管理システムＣ−１，Ｃ−２，Ｃ−３は、携帯端末
上に構築されている。いつ、どのようなネットワークア
ドレスで接続されるか分からない、これらの携帯端末上
の複製ファイル管理システムにＡから接続することは容
易ではない。このような場合に、複製ファイル管理シス
テムＢ上では、だれもチェックインもチェックアウトも
しないが、更新情報はＡと同様に管理されているので、
ＡとＢが同期処理を行えば、Ａでの更新情報はＢに伝わ
る。Ｃ−１，Ｃ−２，Ｃ−３のシステムは、Ｂと同期処
理を行うことにより、複製の更新を行うことができる。
このようなシステムＢを中間リポジトリと呼ぶこととす
る。このような中間リポジトリを操作する人間は、通常
おらず、よって、人手による衝突解決ができないことに
なる。

【００５３】そこで、このような中間リポジトリでは、
衝突を抱え持った状態のまま動き続けるを許すこととす
る。図９を用いて、その実現方法を説明する。ある複製
ファイル管理システムＡに、あるファイルが新規チェッ
クインされたとする。このとき、バージョンＡ−０を生
成する。このファイルは、同期処理により、別の複製フ
ァイル管理システムＢへ複製され、チェックアウトされ
る。システムＡでは、ファイルが更新され、チェックイ
ンされる。このとき、バージョンＡ−１を生成する。一
方、システムＢでもファイルが更新され、チェックイン
される。このとき、バージョンＢ−１を生成する。同期
処理が行われ、システムＡに対して、バージョンＢ−１
に関する更新情報が送られ、バージョンベクタなどの機
構により、更新が衝突していることが検知され、その自
動解決に失敗したとする。このとき、中間リポジトリで
は、ファイルの内容として、Ａ−１の内容、Ｂ−１の内
容の両方をリポジトリへ登録するだけで済ましてしま
う。この場合、次にＢでその後に更新された情報が受信
されれば、バージョンベクタによる管理ではこの衝突を
抱え持った状態（バージョン）に対して、適用可能であ
ると判断されてしまう可能性がある。そこで、衝突を抱
え持った状態を許す場合、図９に示す更新ツリーを管理
し、例えば、バージョンベクタによる管理で衝突してい
なくとも、実際にはどのような更新なのか、更新ツリー
と照らし合わせて管理する。

【００５４】例えば、図９の状態の後で複製ファイル管
理システムＣ−１とＢとの間で同期処理が行われれば、
バージョンＡ−１、バージョンＢ−１の内容の双方が送
られ、ここで、通常と同様に、更新衝突解決が行われ、
失敗するが、それはこれまでと同様に、Ｃ−１を使用し
ているユーザにより解決される。解決すればチェックイ
ンを行うが、その際に、Ａ−１，Ｂ−１の衝突を解決し
た情報を更新情報に含めることにより、更新ツリーが管
理できる。このようにして、自動衝突解決に失敗し、人
手による解決が不可能な複製ファイル管理システムの存
在を許すことができる。

【００５５】実施の形態６．上記では、自動解決に失敗
した衝突を解決し、また更新を行う人間が存在しない場
合について述べたが、ファイルに対する更新はできて
も、衝突解決は判断できなかったり、判断できる立場に
なかったりする場合には、できない場合がある。図１０
を用いて説明する。複製ファイル管理システムＡ上でフ
ァイルが生成され、チェックインされてバージョンＡ−
０が生成され、更新されてＡ−１が生成されたとする。
Ａ−０がチェックインされた後に複製ファイル管理シス
テムＢと同期処理が行われ、更に更新が行われて、バー
ジョンＢ−１が生成されたとする。ここで、同期処理が
再び行われ、Ａ−１とＢ−１の自動衝突解決に失敗した
が、この手動解決を行える人がこのシステムのユーザに
はいないとする。しかし、あるユーザが、Ａ−１に対し
て変更を行いたい場合、この衝突解決が行われるのを待
たなければならない。そこで、Ａ−１に対する更新を許
すこととし、バージョンＡ−２が生成される。ここで、
別の複製ファイル管理システムＣと同期処理が行われる
と、バージョンＡ−２とバージョンＢ−１の自動衝突解
決に失敗することが予測されるが、ここで、手動解決を
行える人が、手動解決を行う。この場合、解決後のチェ
ックインでは、バージョンＡ−２とＢ−１の衝突を解決
したことが更新情報に記録される。このようにして、衝
突と衝突後の更新を許し、更新ツリーを管理することに
より、衝突の手動解決を待たずに、ファイルの更新を続
けて行うことができる。

【００５６】実施の形態７．同じファイルに対して、何
度も更新が行われ、その更新に対してチェックインが行
われれば、それだけ多くの更新情報がリポジトリデータ
ベースに蓄積される。すべての複製ファイル管理システ
ムに更新情報が行き渡れば、その更新情報はもはや蓄積
する必要はない。このような更新情報削除手段を備える
ことにより、リポジトリデータベースが無駄な記憶容量
を使用するのを防ぐことができる。

【００５７】この実現方法を説明する。各複製ファイル
管理システムで、チェックアウトすることのできるバー
ジョンが存在するはずである。そのバージョンの情報
を、中間リポジトリを除いて、すべて収集する。もちろ
ん、これはすべての複製システムと同時に接続して収集
する必要はなく、同期処理によって、段々と伝わってい
くもので十分である。図１０の例で説明すれば、３つの
複製ファイル管理システムがあり、それぞれ、Ａ−１，
Ｃ−１，Ｃ−１のバージョンがチェックアウト可能なら
ば、図１０の更新ツリーをチェックすることにより、新
規バージョンＡ−０の作成及び更新Ａ−１という更新情
報は削除できる。

【００５８】実施の形態８．また、同様に更新履歴管理
ツリーも、更新回数に比例してその容量が増える。この
容量は、更新情報そのものに比べれば小さいが、更新情
報とは異なり、更新履歴管理ツリーは、多くの場合、メ
モリという、ディスクに比べれば容量の小さいものの上
で保持される。従って、この更新履歴管理ツリーの不要
な部分を削除する更新履歴管理ツリー削除手段を備える
ことにより、無駄な記憶容量を使用するのを防ぐことが
できる。これは、前記、更新情報の削除と異なり、すべ
ての複製サイトが同じになった段階以前のものが、削除
されるべきである。すなわち、図１０の例で説明すれ
ば、３つの複製ファイル管理システムがあり、それぞ
れ、Ａ−１，Ｃ−１，Ｃ−１のバージョンがチェックア
ウト可能である場合、更新管理ツリーは削除できない。
それぞれが、Ｃ−１以降のバージョンのチェックアウト
が可能であれば、Ｃ−１以前、すなわち、Ａ−０，Ａ−
１，Ａ−２，Ｂ−１の更新管理ツリーのノードは削除可
能である。

【００５９】実施の形態９．更新情報送受信手段１０４
において、更新情報を送信する際に、圧縮して送信し、
また、受信する際にそれを伸長することにより、更新情
報送受信手段により交される通信量が削減される。これ
は、特に低速あるいは高価な公衆網を介してネットワー
ク接続しているときに有効である。圧縮方法は、一般的
にはｚｉｐ，ｇｚｉｐ，ｌｈａなど一般にファイルの圧
縮に使用されている方法でもよいし、アプリケーション
によってはそれに適した圧縮方法であってもよい。

【００６０】更新ファイルチェックイン手段１０６及び
更新情報記録手段１０３において、ファイルの内容や更
新情報をリポジトリに記録する際に、或いは、更新情報
送受信手段１０４が他の複製ファイル管理システムより
受信した更新情報をリポジトリに記録する際に、圧縮し
て格納することにより、リポジトリデータベースにより
消費される記憶容量が削減され、また伸長せずにそのま
ま送信することにより更新情報送受信手段により交され
る通信量が削減される。これは、特に低速あるいは高価
な公衆網を介してネットワーク接続しているときに有効
である。

【００６１】実施の形態１０．中間リポジトリの説明に
おいて、チェックアウトの必要性は論じなかったが、中
間リポジトリのあるコンピュータシステムは、実は、Ｗ
ＷＷ（ワールドワイドウェブ）サーバであり、複製ファ
イル管理システムにより、管理されている複製ファイル
は、実は、ＷＷＷのコンテンツであるような場合があ
る。このような場合、自動的なチェックアウトが必要で
あるが、これはチェックアウトを人手でなく、プログラ
ムの定期起動や同期処理終了後に行うことで可能であ
る。

【００６２】しかし、自動解決ができない更新衝突が起
こった場合、ユーザファイルの内容は、既にチェックア
ウトされている内容、すなわち古い内容のままか、ユー
ザファイルの内容に適用可能な内容のみ、適用されるこ
ととなる。そこで、各更新情報に優先順位をつけ、その
優先順位に基づいてチェックアウトする内容を決定する
ことにより、特に人間が介在しない複製ファイル管理シ
ステム上でのチェックアウトされる内容をある程度制御
でき、かつ、これまでの、衝突を放置したままで、別の
複製ファイル管理システムでの解決を待つという自由度
も確保することができる。

【００６３】また、優先度情報に、チェックインしたユ
ーザの情報を含むことにより、ユーザの権限に基づく制
御を行うことができる。

【００６４】また、更新量を優先度情報に含むことによ
り、特に更新量が多い更新を優先することにより、些細
な更新との衝突による（一時的ではあるが）情報の欠落
を防ぐことができる。

【００６５】また、特に例に挙げたＷＷＷコンテンツの
ようなものの場合、チェックインをする編集者自身が、
ＷＷＷコンテンツの内容を見ることができる。従って、
チェックイン時刻を優先度情報に含むことにより、より
最新に近い情報に基づくチェックアウト内容への制御を
行うことができる。

【００６６】

【発明の効果】以上のように、この発明によれば、ユー
ザの複製ファイルに対する操作と他の計算機での変更の
記録の収集とその併合処理のタイミングによる問題点が
なくなり、各システムで持つファイルの内容を全て同一
にすることができる。

【００６７】また、この発明によれば、ファイルがバイ
ナリファイルの場合でも、テキストファイルに変換して
差分を取っているので、自動衝突解決に失敗した場合で
も、ユーザの面倒なマージ作業を容易に行うことができ
る。

【００６８】また、この発明によれば、差分情報を更新
情報として記録するので、記憶容量が少量で済む、或い
は、送信量が少なくて済むという効果がある。

【００６９】また、この発明によれば、差分情報を逆適
用可能な差分情報としているので、衝突解決をする場合
に、差分の逆適用及び順適用を行うことにより、衝突解
決を行うことができる。

【００７０】また、この発明によれば、衝突を放置する
ことを許しているので、システムの柔軟性が向上する。

【００７１】また、この発明によれば、衝突を放置した
まま更新することも許しているので、更にシステムの柔
軟性が向上する。

【００７２】また、この発明によれば、更新情報削除手
段により不要になった更新情報を削除するので、記憶領
域の有効利用が図れる。

【００７３】また、この発明によれば、更新履歴管理ツ
リー削除手段により更新履歴管理ツリーの不要になった
ノードを削除するので、記憶領域の有効利用を図ること
ができる。

【００７４】また、この発明によれば、情報を圧縮して
送受信するので、通信量が削減されるという効果があ
る。

【００７５】また、この発明によれば、情報を圧縮して
記録するので、記憶領域の有効利用が図れるという効果
がある。

【００７６】また、この発明によれば、更新の衝突が放
置された場合優先順位に基づいて、チェックアウトする
内容を決定するので、システムの自由度が向上する。

【００７７】また、この発明によれば、ユーザにより優
先順位を決定するので、ユーザオリエンテッドなシステ
ムを構築することができる。

【００７８】また、この発明によれば、更新量が多いも
のを優先させるので、欠落する情報が少なくなるという
効果がある。

【００７９】また、この発明によれば、チェックイン時
刻の新しいものを優先するので、最新の情報を得ること
ができるという効果がある。

【図面の簡単な説明】

【図１】複製ファイル管理システムのコンポーネント
構成図。

【図２】複製ファイル管理システムの動作概要を示す
図。

【図３】リポジトリデータベース管理表を示す図。

【図４】更新履歴管理表を示す図。

【図５】チェックインの動作を示す図。

【図６】チェックアウトの動作を示す図。

【図７】差分更新ツリーの例を示す図。

【図８】中間リポジトリを持つシステムの構成を示す
図。

【図９】衝突を許容する更新ツリーの例を示す図。

【図１０】衝突と更新を許容する更新ツリーの例を示
す図。

【符号の説明】

１０１ユーザファイル、１０２リポジトリデータベ
ース、１０３更新情報記録手段、１０４更新情報送
受信手段、１０５更新適用、衝突解決手段、１０６
更新ファイルチェックイン手段、１０７更新ファイル
チェックアウト手段。

Claims

【特許請求の範囲】

【請求項１】コンピュータシステム上に保持され、共
有されるファイルの複製を管理する複製ファイル管理シ
ステムであって、共用され、複製されるユーザファイルに対し、その内容
と更新内容を記録するリポジトリデータベースと、リポジトリデータベースへ更新されたユーザファイルの
登録を行う更新ファイルチェックイン手段と、リポジトリデータベースからユーザファイルの取出しを
行う更新ファイルチェックアウト手段と、更新されたユーザファイルの情報を更新情報としてリポ
ジトリデータベースへ記録する更新情報記録手段と、更新情報記録手段により記録される更新情報を他の複製
ファイル管理システムと交換する更新情報送受信手段
と、交換により得られた他の複製ファイル管理システムの更
新情報をリポジトリデータベース上のユーザファイルの
内容に適用する、或いは、順序が衝突している更新を解
決する更新適用、衝突解決手段とを備えたことを特徴と
する複製ファイル管理システム。
【請求項２】更新情報記録手段は、ユーザファイルが
バイナリファイルである場合、テキストファイルに変換
して、差分を取り、その差分をリポジトリデータベース
へ記録することを特徴とする請求項１記載の複製ファイ
ル管理システム。
【請求項３】更新情報記録手段は、前回登録されたユ
ーザファイルの内容と今回登録するユーザファイルの内
容との差分を差分更新情報として記録することを特徴と
する請求項１ないし２記載の複製ファイル管理システ
ム。
【請求項４】更新情報記録手段は、差分更新情報とし
て、逆適用可能な差分を使用し、新たな更新情報を記録
する場合に、更新の履歴を管理し、更新適用、衝突解決
手段は、その更新の履歴と差分の逆適用及び順適用によ
り、衝突しているファイルの内容を生成することを特徴
とする請求項３記載の複製ファイル管理システム。
【請求項５】更新情報記録手段は、新たな更新情報を
記録する場合に、更新の履歴を管理し、更新適用、衝突
解決手段は、自動的に解決できなかった衝突を放置する
ことを許すことを特徴とする請求項１ないし２ないし３
ないし４記載の複製ファイル管理システム。
【請求項６】更新適用、衝突解決手段は、更に、衝突
を放置したまま更新することを許すことを特徴とする請
求項５記載の複製ファイル管理システム。
【請求項７】複製ファイル管理システムは、更に、不
要になった更新情報を削除する更新情報削除手段を備え
たことを特徴とする請求項４ないし５ないし６記載の複
製ファイル管理システム。
【請求項８】リポジトリデータベースは、各更新情報
をノードとする更新履歴管理ツリーを記録し、複製ファ
イル管理システムは、更に、不要になった更新履歴管理
ツリーのノードを削除する更新履歴管理ツリー削除手段
を備えたことを特徴とする請求項４，５，６，７いずれ
かに記載の複製ファイル管理システム。
【請求項９】更新情報送受信手段は、更新情報を送信
する際に、圧縮して送信することを特徴とする請求項１
〜８いずれかに記載の複製ファイル管理システム。
【請求項１０】更新情報記録手段は、リポジトリデー
タベースへの登録の際に、情報を圧縮して登録すること
を特徴とする請求項１〜８いずれかに記載の複製ファイ
ル管理システム。
【請求項１１】更新ファイルチェックアウト手段は、
更新の衝突を放置したままユーザファイルの取り出しを
行う場合、更新の優先順位情報に応じて取り出す内容を
決定することを特徴とする請求項５記載の複製ファイル
管理システム。
【請求項１２】優先順位情報は、ユーザファイルを登
録したユーザの情報を含むことを特徴とする請求項１１
記載の複製ファイル管理システム。
【請求項１３】優先順位情報は、更新量情報を含むこ
とを特徴とする請求項１１記載の複製ファイル管理シス
テム。
【請求項１４】優先順位情報は、登録した時刻である
チェックイン時刻を含むことを特徴とする請求項１１記
載の複製ファイル管理システム。