(57)【要約】【課題】  ユーザ間の意思伝達を効率的に行う変更履歴の管理手段を提供すること。【解決手段】  リポジトリが、ユーザ端末１ごとに特定のユーザ端末１の利用者のみにアクセスさせる更新対象のファイルを管理するユーザリポジトリ２６と、任意のユーザ端末１にアクセスさせる更新対象のファイルを管理するシステムリポジトリ２２により構成され、リポジトリサーバ２が、ユーザリポジトリ２６の更新対象のファイルをユーザ端末１に更新させる手順と、ユーザリポジトリ２６の更新対象のファイルをシステムリポジトリ２２に書き込むようユーザ端末１に更新させる手順と、システムリポジトリ２２の更新対象のファイルを任意のユーザ端末１に読み取らせる手順と、を実行する。【選択図】      図１
2006134214.tif 000002
【特許請求の範囲】
【請求項１】
記憶手段に格納されるリポジトリによってバージョン管理される更新対象のファイルを格納するリポジトリサーバと、前記更新対象のファイルにアクセスするユーザ端末とを含む計算機システムによるファイルのバージョン管理方法であって、
前記リポジトリは、ユーザ端末ごとに特定のユーザ端末の利用者のみにアクセスさせる更新対象のファイルを管理するユーザリポジトリと、任意のユーザ端末にアクセスさせる更新対象のファイルを管理するシステムリポジトリとにより構成され、
前記リポジトリサーバが、
ユーザリポジトリの更新対象のファイルをユーザ端末に更新させる手順と、前記ユーザリポジトリの更新対象のファイルをシステムリポジトリに書き込むようユーザ端末に更新させる手順と、前記システムリポジトリの更新対象のファイルを任意のユーザ端末に読み取らせる手順と、
を実行することを特徴とするファイルのバージョン管理方法。
【請求項２】
前記リポジトリサーバは、前記更新対象のファイルについてバージョンごとに異なるファイルを作成し、他の前記更新対象のファイルと区別するためのユニークなファイル名を付して、そのユニークなファイル名を前記リポジトリに格納することを特徴とする請求項１に記載のファイルのバージョン管理方法。
【請求項３】
前記リポジトリサーバは、更新対象のファイルを他の更新対象のファイルと区別するためのユニークなファイルＩＤ、および、同じファイルＩＤとなりバージョンが異なる複数の更新対象のファイルについて、バージョンを一意に特定するためのバージョンＩＤを発行し、前記ファイルＩＤおよび前記バージョンＩＤをリポジトリに格納することを特徴とする請求項１または請求項２に記載のファイルのバージョン管理方法。
【請求項４】
前記システムリポジトリの更新対象のファイルを任意のユーザ端末に読み取らせる手順は、
前記リポジトリサーバが、前記ファイルＩＤをキーとして、そのファイルＩＤに対応するファイルについて、記録している全バージョンをリストアップすることを特徴とする請求項３に記載のファイルのバージョン管理方法。
【請求項５】
前記システムリポジトリの更新対象のファイルを任意のユーザ端末に読み取らせる手順は、
前記リポジトリサーバが、ファイルＩＤおよびバージョンＩＤをキーとして、そのファイルＩＤおよびバージョンＩＤに対応するバージョンがリポジトリにあるか否かという情報を返信することを特徴とする請求項３に記載のファイルのバージョン管理方法。
【請求項６】
前記システムリポジトリの更新対象のファイルを任意のユーザ端末に読み取らせる手順は、
前記リポジトリサーバが、前記ユニークなファイル名をキーとして、その前記ユニークなファイル名がリポジトリに格納されているときに、そのファイルの内容を返すことを特徴とする請求項３に記載のファイルのバージョン管理方法。
【請求項７】
リポジトリによってバージョン管理される更新対象のファイルを格納するリポジトリサーバと、前記更新対象のファイルにアクセスするユーザ端末とを含む計算機システムであって、
前記リポジトリは、ユーザ端末ごとに特定のユーザ端末の利用者のみにアクセスさせる更新対象のファイルを管理するユーザリポジトリと、任意のユーザ端末にアクセスさせる更新対象のファイルを管理するシステムリポジトリとにより構成され、
前記リポジトリサーバが、
ユーザリポジトリの更新対象のファイルをユーザ端末に更新させるユーザリポジトリ更新部と、前記ユーザリポジトリの更新対象のファイルをシステムリポジトリに書き込むようユーザ端末に更新させるシステムリポジトリ更新部と、前記システムリポジトリの更新対象のファイルを任意のユーザ端末に読み取らせる履歴管理部と、
を有することを特徴とする計算機システム。
【請求項８】
前記履歴管理部は、前記更新対象のファイルについてバージョンごとに異なるファイルを作成し、他の前記更新対象のファイルと区別するためのユニークなファイル名を付して、そのユニークなファイル名を前記リポジトリに格納することを特徴とする請求項７に記載の計算機システム。
【請求項９】
前記履歴管理部は、更新対象のファイルを他の更新対象のファイルと区別するためのユニークなファイルＩＤ、および、同じファイルＩＤとなりバージョンが異なる複数の更新対象のファイルについて、バージョンを一意に特定するためのバージョンＩＤを発行し、前記ファイルＩＤおよび前記バージョンＩＤをリポジトリに格納することを特徴とする請求項７または請求項８に記載の計算機システム。
【請求項１０】
リポジトリによってバージョン管理される更新対象のファイルを格納するリポジトリサーバと、前記更新対象のファイルにアクセスするユーザ端末とを含む計算機システムであって、
前記リポジトリサーバは、
磁気ディスクに格納されているデータをファイルという単位でユーザ端末に認識させるファイルシステムと、ファイルシステムのアクセスを仲介するオペレーティングシステムと、ファイルシステムからの制御命令を実行して、記憶手段を制御するデバイスドライバと、バージョン管理サービスを提供するために必要なデータを保存する記憶媒体と、
更新したファイルの内容を格納するファイルデータ格納部と、ユーザごとに割り当てられた一時的な更新のための領域における、ファイル更新の履歴に関する情報を管理するユーザリポジトリと、ユーザごとに割り当てられた一時的な領域について、割り当てられた本人の端末のみにアクセスを許可するようにし、他人の端末にはアクセスさせないようにするユーザリポジトリ更新部と、各ユーザに公開する更新対象となる全ファイルの更新履歴に関する情報を格納するシステムリポジトリと、ユーザリポジトリの一時的な更新を、システムリポジトリに反映するシステムリポジトリ更新部と、
システムリポジトリとユーザリポジトリとのファイルを対応付けるテーブルである履歴管理テーブルと、ユーザ端末が送信したファイル操作要求を受信し、受信したファイル操作要求に応じて、ファイルおよびその履歴の取得、ファイルの書き込み、および、他ユーザへのファイルの同期を行う履歴管理部と、アクセス要求のあったユーザ端末に対して認証を行い、利用させるサービスを決定するユーザ認証部と、を有することを特徴とする計算機システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルのバージョン管理方法および計算機システムに関する。
【背景技術】
【０００２】
プログラム、文章、図面などのファイルを継続的に編集する際に、開発者などの編集者が変更履歴を管理するとなると、行わなければならない仕事が増えてしまう。そこで、ファイルの変更内容を変更履歴として一元管理し、任意の時点の履歴を取り出す作業を、計算機に行わせる手段が提案されている。
【０００３】
例えば、ＣＶＳ（Concurrent Versions System）は、ファイルのバージョンを管理するソフトウェアである。ＣＶＳプログラムが動いている単一の計算機（ＣＶＳサーバ）は、リポジトリと呼ばれる記憶領域を用意し、そこに複数の開発者（ユーザ）から送られてきたファイルを蓄積する。
【０００４】
ユーザは、ＣＶＳサーバに対し、ＣＶＳ固有のコマンドを発行することにより、リポジトリからのファイルの取り出し、リポジトリへの格納を行う。ユーザがＣＶＳサーバに対してファイルの更新を要求した場合、ＣＶＳサーバは過去のファイルを消さずに、変更の差分を履歴としてリポジトリに保存する。ユーザは、ＣＶＳサーバに要求を発行することで、リポジトリに履歴として残ったファイルをいつでも取り出すことができる。
【０００５】
しかし、ＣＶＳによるバージョン管理を実現するためには、ユーザがＣＶＳの使い方を学習し、ユーザがＣＶＳ固有のコマンドを発行して履歴の保存を計算機に指示する必要がある。そのため、ＣＶＳ固有のコマンドを学習するためのコストがかかってしまう。そこで、ＣＶＳ固有のコマンドをユーザには直接見せず、ユーザが使い慣れたインタフェースからＣＶＳを間接的に操作させるような技術が提案されている。
【０００６】
ＣＶＳを間接的に操作させる一例として、オペレーティングシステム上のファイルシステムにＣＶＳを取り込んだ技術が、非特許文献１に開示されている。この技術によれば、ユーザからのファイル操作要求を受け取った計算機が、そのファイル操作要求に加えてバージョン管理の発行要求も行う。このようなバージョン管理によって、ユーザはファイルを格納するだけでファイルの履歴を残すことができるため、ユーザに負担をかけることなく、ユーザは確実に履歴を残すことが可能となる。
【０００７】
また、ＣＶＳを間接的に操作させる別の一例として、ユーザがファイルを更新したときに、元のファイルデータを上書きせず、常に別の空き領域に新しいファイルデータを書き込むファイルシステム技術が、特許文献１に開示されている。この技術によれば、この計算機が管理しているファイルへの参照情報全てを、定期的に履歴として保存する。ファイルシステムは、ファイルデータと共に、そのファイルへの参照情報を記憶装置に格納する。ファイルシステムは、ファイルへの参照情報が存在する限り、参照情報が参照するファイルデータを消すことはないため、ファイルへの参照情報全てを保存することで、ファイルデータを残すことができる。
【０００８】
このようなファイルシステムによって、ユーザは履歴を残すことを意識することなく、確実に履歴を残すことが可能となる。また、計算機はファイルへの参照情報のみをコピーすることで、ファイル自体をコピーするよりもデータのコピー量が少なくてすむため、高速な履歴保存が可能となる。
【特許文献１】ＵＳＰ６２８９３５６号公報
【非特許文献１】Nanjing, China:“An Adaptive Version-Controlled File System",Proceedings of The Forth International Symposium on Future Software Technology (ISFST'99), pp.36-41, October 27-29, 1999
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、従来の変更履歴の管理技術では、複数のソフトウェア開発者が１つのソフトウェア開発を行う場合や、複数の設計者が１つの大きな図面を設計する場合など、複数のユーザが意味の一貫性を持ったファイルの集合を編集する場合において、複数のユーザが連携して編集作業を行う用途には、充分には適していない。
【００１０】
例えば、開発者Ａが作成中であるプログラムＣを、リポジトリにアップデートする。ここで、開発者Ａは、プログラムＣに対する動作テストを充分に行っていないため、他の開発者には、プログラムＣを見せたくないと思っている。
【００１１】
しかし、別の開発者Ｂは、通常のリポジトリのアクセスコマンドにより、そのプログラムＣを取得することができてしまう。その結果、プログラムＣがバグを含んでいたとすると、別の開発者Ｂは、そのバグによって時間を浪費してしまう。この時間の浪費は、開発者Ａの“プログラムＣを見せたくない”という意思が、リポジトリに反映されていれば、本来防げたはずの問題である。
【００１２】
なお、ユーザがファイルを更新するときに、その更新内容をコメントとして付加する機構が考えられる。これにより、ファイルの更新を行ったユーザは、他のユーザにファイルの更新内容を通知することができる。複数のユーザが、例えば複数のファイルからなるプログラムのような、意味の一貫性が要求されるファイルを編集している場合、ユーザは更新内容のコメントを元に、そのユーザが編集しているファイルを他のファイルとの一貫性を維持するために修正することができる。
【００１３】
しかし、このコメントによる意思の伝達は、単に人間が読むテキストデータにすぎず、難解な表現や読者の不注意などによりコメントが読まれない可能性もある。よって、ある開発者が行ったファイルの変更内容が他の開発者に通知されず、開発者間の連携がうまくいかないという問題がある。
【００１４】
そこで、本発明は、ユーザ間の意思伝達を効率的に行う変更履歴の管理手段を提供することを主な目的とする。
【課題を解決するための手段】
【００１５】
前記課題を解決するため、リポジトリによってバージョン管理される更新対象のファイルを格納するリポジトリサーバと、前記更新対象のファイルにアクセスするユーザ端末とを含む計算機システムによるファイルのバージョン管理方法は、前記リポジトリが、ユーザ端末ごとに特定のユーザ端末の利用者のみにアクセスさせる更新対象のファイルを管理するユーザリポジトリと、任意のユーザ端末にアクセスさせる更新対象のファイルを管理するシステムリポジトリにより構成され、前記リポジトリサーバが、ユーザリポジトリの更新対象のファイルをユーザ端末に更新させる手順と、前記ユーザリポジトリの更新対象のファイルをシステムリポジトリに書き込むようユーザ端末に更新させる手順と、前記システムリポジトリの更新対象のファイルを任意のユーザ端末に読み取らせる手順と、を実行することを主な特徴とする。その他の構成は、後記する。
【発明の効果】
【００１６】
本発明は、リポジトリを、ユーザごとに隠蔽するユーザリポジトリと、全ユーザに公開するシステムリポジトリとに分けるように、リポジトリサーバがユーザ端末のアクセスを制御することを特徴とする。これにより、ユーザ端末は、公開を望まないファイルをユーザリポジトリに、公開したいファイルをシステムリポジトリに更新するように、使い分けるようになる。よって、このリポジトリの使い分けにより、ユーザ間の意思伝達を効率的に行うことが可能となった。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施の形態を、図面を用いて説明する。図１は、計算機システムを示す構成図である。
【００１８】
計算機システムは、複数のユーザ端末１およびリポジトリサーバ２を含めて構成される。そして、各ユーザ端末１は、リポジトリサーバ２と通信回線で接続される。ユーザ端末１は、バージョン管理システムの利用者が操作する端末であり、このユーザ端末１を介してファイルの更新および取得が行われる。また、リポジトリサーバ２は、ユーザにバージョン管理サービスを提供する。
【００１９】
なお、ユーザ端末１およびリポジトリサーバ２は、演算処理を行う際に用いられる記憶手段としてのメモリと、前記演算処理を行う演算処理装置とを少なくとも備えるコンピュータとして構成される。なお、メモリは、ＲＡＭ（Random Access Memory）などにより構成される。演算処理は、ＣＰＵ（Central Processing Unit）によって構成される演算処理装置が、メモリ上のプログラムを実行することで、実現される。
【００２０】
さらに、ユーザ端末１およびリポジトリサーバ２は、ユーザ端末１からの要求を受信し、ユーザ端末１に要求の結果を返信するための入出力手段であるユーザインタフェース（図示は省略）を有する。このユーザインタフェースは、例えば、ディスプレイとキーボードや、ユーザ端末１とネットワークで通信する際の通信機能である。
【００２１】
そして、リポジトリサーバ２は、ファイルシステム１２のアクセスを仲介するオペレーティングシステム１０と、磁気ディスクに格納されているデータをファイルという単位でユーザ端末１に認識させるファイルシステム１２と、ファイルシステム１２からの制御命令を実行して、記憶手段を制御するデバイスドライバ１４と、バージョン管理サービスを提供するために必要なデータを保存する記憶媒体１６と、を備える。ここで、後記するリポジトリは、記憶媒体１６に格納される。
【００２２】
なお、ファイルシステム１２により、ユーザ端末１は、データのディスク媒体面上のアドレスを直接指定することなく、ファイル名を指定するだけで、目的とするデータにアクセスできる。ユーザが送信したファイルアクセス命令を磁気ディスク固有の制御命令に変換して、デバイスドライバ１４に与える。
【００２３】
また、デバイスドライバ１４は、例えば、磁気ディスク固有の命令体系として、ＳＣＳＩ（Small Computer System Interface）やＡＴＡ（AT Attachment）規格を用いてもよい。さらに、記憶媒体１６は、例えば、磁気ディスクとして構成されるが、これに限定されることはなく、記憶媒体１６の種類に依存せずに構成することができる。磁気ディスクの記憶媒体１６面上のビット列によって、ファイルという形式でデータを格納する。
【００２４】
図２は、ファイル更新処理の概要を示すフローチャートである。そして、図３は、ファイル更新処理の概要におけるリポジトリの内容を示す説明図である。以下、図２および図３に沿って、本実施形態における２種類のリポジトリ（システムリポジトリ２２とユーザリポジトリ２６、図４参照）の使い分けについて、概要を説明する。なお、説明の便宜上、ユーザ端末１を、ファイルを更新する開発側端末２Ａと、更新されたファイルを取得する利用側端末２Ｂとに区別して説明するが、両端末の機能上の違いはない。なお、図２で説明する各構成要素については、図４などに後記するものとする。
【００２５】
まず、初回のファイルの作成（バージョン１）について、説明する。開発側端末２Ａは、ファイルを新規に作成する（Ｓ１００）。次に、開発側端末２Ａは、図３（ａ）のように、作成したファイルを、リポジトリサーバ２のユーザリポジトリ２６に更新する（Ｓ１０１）。そして、開発側端末２Ａは、図３（ｂ）のように、ユーザリポジトリ２６に存在する作成したファイルを、リポジトリサーバ２のシステムリポジトリ２２に更新する（Ｓ１０２）。さらに、利用側端末２Ｂは、リポジトリサーバ２から登録されているファイルに対して検索要求を行う（Ｓ１０３）。すると、リポジトリサーバ２は、Ｓ１０２でシステムリポジトリ２２に登録されたファイル（バージョン１）を発見し、そのファイルを利用側端末２Ｂに提供する。
【００２６】
次に、ファイルの修正（バージョン２）について、説明する。開発側端末２Ａは、バージョン１のファイルをバージョン２に修正する（Ｓ１１１）。次に、開発側端末２Ａは、図３（ｃ）のように、修正したバージョン２のファイルを、リポジトリサーバ２のユーザリポジトリ２６に更新する（Ｓ１１２）。ここで、例えば修正したバージョン２のファイルに欠陥が見つかったため、システムリポジトリ２２の更新は行わないものとする。
【００２７】
そして、利用側端末２Ｂは、リポジトリサーバ２から登録されているファイルに対して検索要求を行う。すると、リポジトリサーバ２は、Ｓ１０２でシステムリポジトリ２２に登録されたファイル（バージョン１）を発見し、そのファイルを利用側端末２Ｂに提供する。つまり、Ｓ１１２でユーザリポジトリ２６に登録されたバージョン２のファイルは、まだシステムリポジトリ２２に登録されていないので、利用側端末２Ｂは、このファイルを取得することが、リポジトリサーバ２のアクセス制御により禁止されている。
【００２８】
そして、さらなるファイルの修正（バージョン３）について、説明する。開発側端末２Ａは、バージョン２のファイルを修正し、バージョン３とする（Ｓ１２１）。次に、開発側端末２Ａは、図３（ｄ）のように、さらに修正したファイルを、リポジトリサーバ２のユーザリポジトリ２６に更新する（Ｓ１２２）。そして、開発側端末２Ａは、図３（ｅ）のように、さらに修正したファイルを、リポジトリサーバ２のシステムリポジトリ２２に更新する（Ｓ１２３）。さらに、利用側端末２Ｂは、リポジトリサーバ２から登録されているファイルの検索要求を行う（Ｓ１２４）。すると、リポジトリサーバ２は、Ｓ１２３でシステムリポジトリ２２に登録されたファイル（バージョン３）を発見し、そのファイルを利用側端末２Ｂに提供する。
【００２９】
以上のように、リポジトリサーバ２は、ファイルを更新するユーザに対しては、特定のユーザごとにそのユーザのみがアクセス可能なユーザリポジトリ２６と、全ユーザが参照可能なシステムリポジトリ２２とを有する。そして、特定のユーザ（開発側端末２Ａ）によるファイルの更新は、ユーザリポジトリ２６への第１段階の更新と、第１段階によってユーザリポジトリ２６内に更新されたファイルをシステムリポジトリ２２へ更新する第２段階の更新と、の２段階の更新となる。
【００３０】
図４は、リポジトリサーバ２を示す構成図である。リポジトリサーバ２は、ファイルの更新履歴を格納するために、更新したファイルの内容を格納するファイルデータ格納部２０と、各ユーザに公開する更新対象となる全ファイルの更新履歴に関する情報を格納するシステムリポジトリ２２と、ユーザリポジトリ２６の一時的な更新を、システムリポジトリ２２に反映するシステムリポジトリ更新部２４と、ユーザごとに割り当てられた一時的な更新のための領域における、ファイル更新の履歴に関する情報を管理するユーザリポジトリ２６と、ユーザごとに割り当てられた一時的な領域について、割り当てられた本人のみにアクセスを許可するようにし、他人にはアクセスさせないようにするユーザリポジトリ更新部２８と、を有する。
【００３１】
なお、ユーザリポジトリ更新部２８は、あるユーザ端末１がファイルを更新したときに、更新したファイルを一時的な領域に保存し、他のユーザにその更新したファイルをアクセスさせないように、ディスクアクセスを制御する。また、ユーザリポジトリ２６の各レコードは、そのレコードがどのユーザのものかを識別するために、ユーザＩＤを有している。このユーザＩＤは、アクセスしたユーザに応じて、付加される。
【００３２】
そして、リポジトリサーバ２は、ファイルの更新履歴を管理するために、システムリポジトリ２２とユーザリポジトリ２６とのファイルを対応付けるテーブルである履歴管理テーブル３０と、ユーザ端末１が送信したファイル操作要求を受信し、受信したファイル操作要求に応じて、ファイルおよびその履歴の取得、ファイルの書き込み、他ユーザへのファイルの同期を行う履歴管理部３２と、を有する。
【００３３】
さらに、リポジトリサーバ２は、ユーザによってアクセスするファイルを制限するために、アクセス要求のあったユーザ端末１に対して認証を行い、利用させるサービスを決定するユーザ認証部３４を有する。このユーザ認証部３４は、ユーザＩＤおよびパスワードの組を入力させ、リポジトリサーバ２内にあらかじめ登録されたユーザアカウントにおけるユーザＩＤおよびパスワードの組と照合するような、既存の認証手段であれば、とくにその認証手段は限定されることはない。
【００３４】
図５は、リポジトリのデータ構造を示す説明図である。このデータ構造は、システムリポジトリ２２およびユーザリポジトリ２６において格納される個々のリポジトリの構造を示すものである。１つのファイルエントリ１００が、１つの更新対象のファイルに対応する。そして、１つの更新対象のファイルが複数回更新されるときに、１回の更新により、１つのバージョンエントリ１１０が作成される。よって、１つのファイルエントリ１００は、１つ以上のバージョンエントリ１１０を含めて構成される。そして、ファイルエントリ１００は、他のファイルエントリ１００と区別するために、一意となるファイルＩＤ１０２が割り当てられる。このファイルＩＤ１０２は、例えば英数文字から構成されるファイル名である。
【００３５】
バージョンエントリ１１０は、以下の情報を含む。まず、バージョンＩＤ１１２は、ファイルのバージョンを一意に識別するための番号であり、バージョンごとに発行されるＩＤである。さらに、バージョンエントリ１１０は、このファイルのバージョンを更新した時点での日時を表す更新日時１１４と、このファイルのバージョンを更新したユーザを一意に識別する情報（ユーザＩＤ、ユーザ名など）である更新者１１６と、このファイルのバージョンに関し、更新者１１６が任意に作成するテキスト情報を格納する更新者コメント１１８と、バージョンエントリ１１０と、そのバージョンのファイルを一意に対応付けるバージョン保存用ファイル名１２０と、を含めて構成される。つまり、バージョン保存用ファイル名１２０は、他のバージョンエントリ１１０におけるファイル名と同じでは衝突が発生するため、異なるファイル名を付けなければならない。
【００３６】
バージョンエントリ１１０のバージョン保存用ファイル名１２０から参照可能なバージョン保存用ファイル１２２は、ファイルの特定のバージョンに対応するファイルデータである。このファイルデータは、同じファイルＩＤ１０２となる別バージョンのバージョン保存用ファイル１２２からの差分ファイルとしてもよいし、データ内容を全て含むような、別バージョンとは独立したファイルとしてもよい。
【００３７】
ここで、履歴管理テーブル３０は、同じファイルＩＤ１０２となる更新対象のファイルにおいて、ユーザごとに異なったバージョンエントリ１１０のバージョン保存用ファイル１２２にアクセスさせるために参照される。なお、複数のユーザが同じファイルＩＤ１０２となるファイルを同時に編集していても、編集内容はお互いに異なるバージョンエントリ１１０のバージョン保存用ファイル１２２に保存されている。よって、ユーザごとに別々のバージョン保存用ファイル１２２を編集しているため、あるユーザの編集内容が、別のユーザの編集作業と衝突することはない。
【００３８】
図６は、履歴管理テーブル３０の一例を示す構成図である。履歴管理テーブル３０は、個々のファイル更新について、ファイルＩＤ１０２と、格納先となるリポジトリ（システムまたは特定ユーザ）と、ファイル更新のデータ内容を格納するバージョン保存用ファイル名１２０と、の対応付けを保持している。そして、同じファイルＩＤ１０２でもユーザが異なると、更新するファイルが異なることを特徴とする。例えば、ファイルＩＤ１０２“／ｆｏｏ／ｆｉｌｅＡ”のバージョン４．３は、システムリポジトリ２２に存在し、かつ、ユーザＸとユーザＹそれぞれのユーザリポジトリ２６にも存在する。そして、ユーザＸが更新しているファイルＩＤ１０２“／ｆｏｏ／ｆｉｌｅＡ”のバージョン４．３は、実際には“Ａ００２”というファイルであり、ユーザＹが更新しているファイルＩＤ１０２“／ｆｏｏ／ｆｉｌｅＢ”のバージョン４．３は、実際には“Ａ００３”というファイルである。つまり、同じファイルＩＤ１０２の同じバージョンであっても、ユーザごとに更新するファイルの実体は、異なるものとする。これにより、複数のユーザが、衝突することなくファイルを並列に編集させることができる。
【００３９】
以下、前記の図２に沿って説明したファイルの更新処理について、具体的に説明する。まず、ユーザリポジトリ２６の更新処理（図２におけるＳ１０１、Ｓ１１２、Ｓ１２２）について、図７に沿って説明する。なお、図７の処理の主体は、リポジトリサーバ２とする。なお、ユーザリポジトリ２６の更新処理は、ファイルの内容そのものの変更や、当該ファイルに関する情報の変更を指す。ＵＮＩＸ（登録商標）のコマンドで言えば、エディタで当該ファイルを変更する操作や、ｃｈｍｏｄコマンドでファイルの属性を変更する操作に対応する。
【００４０】
また、以下の説明においてファイルの更新処理を説明するために、図８に示す履歴管理テーブル３０の更新の変移を、適宜参照する。まず、初期状態として、図８（ａ）のように、更新対象のファイルがシステムリポジトリ２２に１つあるものとする。
【００４１】
なお、リポジトリサーバ２は、ユーザごとに用意したユーザリポジトリ２６を、そのユーザだけにアクセスを許可するようなアクセス制御を行う。よって、リポジトリサーバ２のユーザ認証部３４は、ユーザ端末１の認証を行い、そのユーザに対応するユーザリポジトリ２６へのアクセスを許可し、別のユーザに対応するユーザリポジトリ２６へのアクセスを禁止する。以下の説明では、ユーザが自分のユーザリポジトリ２６へアクセスすることを前提として、説明を行う。
【００４２】
リポジトリサーバ２は、開発側端末２Ａからユーザリポジトリ２６の更新要求を受信する（Ｓ２０１）。この更新要求は、ファイルＩＤ１０２を含み、ファイルの内容、または、ファイルの内容の格納場所を示す情報（例えば、システムリポジトリ２２に格納されているファイルＩＤ１０２とバージョンＩＤ１１２との組）も含むものとする。すると、リポジトリサーバ２は、要求されたファイルがユーザリポジトリ２６に存在するかどうかを検索する（Ｓ２０２）。
【００４３】
まず、要求されたファイルが既に存在するときは（Ｓ２０２、ＹＥＳ）、そのファイルのファイルエントリ１００は、既にユーザリポジトリ２６に生成されているので、そのユーザエントリに今回の更新に対応するバージョンエントリ１１０を１つ追加する。具体的には、リポジトリサーバ２は、ユーザリポジトリ２６の今まで最新であった既存のファイルを旧バージョンとして、ユーザリポジトリ２６に保存し（Ｓ２０３）、送信されたファイルを最新バージョンとして、ユーザリポジトリ２６に保存する（Ｓ２０４）。このＳ２０３とＳ２０４でそれぞれ保存されるファイルは、それぞれが別バージョンのファイルなので、ファイル名が衝突しないようにする。例えば、図８（ｃ）は、ユーザＸのユーザリポジトリ２６において、既存のファイルエントリ１００に新たなバージョンエントリ１１０（バージョン１．２）が生成された一例を示すものである。
【００４４】
なお、リポジトリサーバ２は、システムリポジトリ２２またはユーザリポジトリ２６のデータを更新したときには、履歴管理部３２が履歴管理テーブル３０にその旨を反映する。
【００４５】
履歴管理部３２が履歴管理テーブル３０を更新する処理は、次の通りである。履歴管理部３２は、システムリポジトリ２２またはユーザリポジトリ２６に作成されたバージョンエントリ１１０とバージョン保存用ファイル名１２０との対応情報を、履歴管理テーブル３０に更新する。ここで、履歴管理部３２は、新たなバージョンエントリ１１０を生成するときには、旧ファイルの旧バージョンＩＤ１１２よりも大きい数値を設定する。さらに履歴管理部３２は、更新日時１１４に更新が発生した日時を設定し、更新者１１６には更新を指示したユーザの識別子を設定する。更新者コメント１１８には、更新を指示したユーザが入力した文字列を設定する。最後にバージョン保存用ファイル名１２０には、更新した新ファイル名の実体ファイル名を設定する。これらの設定したバージョンエントリ１１０をユーザリポジトリ２６に追記する。
【００４６】
一方、要求されたファイルが存在しないときは（Ｓ２０２、ＮＯ）、そのファイルのファイルエントリ１００は、まだユーザリポジトリ２６に生成されていない。よって、リポジトリサーバ２は、開発側端末２Ａから指定されたファイルＩＤ１０２に対応するファイルをシステムリポジトリ２２から取得し、新エントリの初回バージョンとして、ユーザリポジトリ２６に保存する（Ｓ２０５）。換言すると、リポジトリサーバ２は、新しいファイルエントリ１００およびそのファイルエントリ１００に属する新しいバージョンエントリ１１０を、１つずつ作成する。例えば、図８（ｂ）は、ユーザＸのユーザリポジトリ２６に、新たなファイルエントリ１００およびバージョンエントリ１１０（バージョン１．１）が生成された一例を示すものである。なお、初回バージョンのバージョンＩＤ１１２は、任意の数値とする。そして、履歴管理部３２は、Ｓ２０５で更新したユーザリポジトリ２６について、履歴管理テーブル３０にその旨を反映する。
【００４７】
次に、図７の処理によって更新されたユーザリポジトリ２６のファイルデータを、システムリポジトリ２２に反映するシステムリポジトリ２２の更新処理（図２におけるＳ１０２、Ｓ１２３）について、図９に沿って説明する。なお、図９の処理の主体は、リポジトリサーバ２とする。
【００４８】
まず、リポジトリサーバ２は、開発側端末２Ａからシステムリポジトリ２２の更新要求を受信する（Ｓ３０１）。この更新要求は、更新対象のファイルを特定するファイルＩＤ１０２を含むものとする。すると、リポジトリサーバ２は、要求されたファイルがユーザリポジトリ２６に存在するかどうかを検索する（Ｓ３０２）。
【００４９】
まず、要求されたファイルがユーザリポジトリ２６に存在するときは（Ｓ３０２、ＹＥＳ）、リポジトリサーバ２は、要求されたファイルの最新バージョンを、システムリポジトリ２２にコピーする。具体的には、リポジトリサーバ２は、システムリポジトリ２２の今まで最新であった既存のファイルを旧バージョンとして、システムリポジトリ２２に保存し（Ｓ３０３）、ユーザリポジトリ２６のファイルを最新バージョンとして、システムリポジトリ２２に保存する（Ｓ３０４）。このシステムリポジトリ２２に保存された２つのバージョン（Ｓ３０３で保存するバージョン、Ｓ３０４で保存するバージョン）は、互いにバージョンＩＤ１１２およびバージョン保存用ファイル名１２０が重複しないようにする。そして、履歴管理部３２は、Ｓ３０３およびＳ３０４で更新したシステムリポジトリ２２について、履歴管理テーブル３０にその旨を反映する。
【００５０】
例えば、図８（ｄ）は、ユーザＸのユーザリポジトリ２６を、システムリポジトリ２２に反映する例を示す。つまり、システムリポジトリ２２のバージョン１．１が旧バージョンとして保存され（Ｓ３０３）、システムリポジトリ２２のバージョン１．２が、ユーザＸのユーザリポジトリ２６からコピーされている（Ｓ３０４）。
【００５１】
一方、要求されたファイルがユーザリポジトリ２６に存在しないときは（Ｓ３０２、ＮＯ）、リポジトリサーバ２は、開発側端末２Ａに更新できない旨のエラーメッセージを送信する（Ｓ３０５）。
【００５２】
さらに、図９の処理によって更新されたシステムリポジトリ２２のファイルデータを、全ユーザにアクセスさせるためのリポジトリからのファイルの検索処理（図２におけるＳ１０３、Ｓ１１３、Ｓ１２４）について、図１０に沿って説明する。なお、図１０の処理の主体は、リポジトリサーバ２とする。
【００５３】
まず、リポジトリサーバ２は、利用側端末２Ｂから検索要求を受信する（Ｓ４０１）。この検索要求は、検索対象のファイルＩＤ１０２を含み、検索対象のバージョンＩＤ１１２を含めてもよい。すると、リポジトリサーバ２は、検索条件に適合するファイルをリポジトリ（ユーザリポジトリ２６およびシステムリポジトリ２２）から検索する（Ｓ４０２）。なお、検索要求に含まれる検索条件は、例えば、次の３種類の条件が挙げられる。
【００５４】
第１の検索条件は、ファイルＩＤ１０２をキーとして、そのファイルＩＤ１０２に対応するファイルについて、記録している全バージョンをリストアップする旨の、検索条件である。この検索条件は、ファイルに関する情報の取得を示し、ＵＮＩＸ（登録商標）のコマンドで言えば、ｌｓコマンドでファイルの更新日時、所有者、属性を表示する操作に対応する。
【００５５】
第２の検索条件は、ファイルＩＤ１０２およびバージョンＩＤ１１２をキーとして、そのファイルＩＤ１０２およびバージョンＩＤ１１２に対応するバージョンの有無（つまり、キーとなるファイルＩＤ１０２のファイルエントリ１００が、キーとなるバージョンＩＤ１１２のバージョンエントリ１１０を有しているか否か）を判定する旨の、検索条件である。
【００５６】
第３の検索条件は、ファイルＩＤ１０２の代わりに、ファイル名をキーとして、そのファイル名に対応するバージョン保存用ファイル名１２０がリポジトリに格納されているときに、そのファイルの内容を返す旨の、検索条件である。この検索条件は、ファイルの内容そのものの取得を示し、ユーザ端末１がエディタで当該ファイルを開く操作に該当する。
【００５７】
もし、検索結果としてユーザリポジトリ２６から検索条件に適合するファイルが発見されたら（Ｓ４０３、ユーザ）、リポジトリサーバ２は、ユーザリポジトリ２６のファイル情報を、Ｓ４０２で指定された検索条件に適合する形式で利用側端末２Ｂに返信する（Ｓ４０４）。
【００５８】
または、検索結果としてシステムリポジトリ２２から検索条件に適合するファイルが発見されたら（Ｓ４０３、システム）、リポジトリサーバ２は、システムリポジトリ２２のファイル情報を、Ｓ４０２で指定された検索条件に適合する形式で利用側端末２Ｂに返信する（Ｓ４０５）。
【００５９】
ここで、検索条件に適合するファイルが、システムリポジトリ２２とユーザリポジトリ２６との両方から発見されたときには、両方のファイルを返してもよいし、どちらか一方（例えば、ユーザリポジトリ２６）を優先させてもよい。
【００６０】
一方、検索結果としてＳ４０２の検索条件に適合するファイルが発見されなかったら（Ｓ４０３、なし）、リポジトリサーバ２は、利用側端末２Ｂに発見されなかった旨のエラーメッセージを返信する（Ｓ４０６）。
【００６１】
以上説明した本実施形態の要約は、次の通りである。
【００６２】
リポジトリサーバ２は、オペレーティングシステム１０とデータを保存する記憶媒体１６を有する。オペレーティングシステム１０は、記憶媒体１６内に履歴管理テーブル３０を持ち、履歴管理テーブル３０は、あるファイルに関して、あるユーザが認識しているファイルのファイル名と記憶媒体１６内で実際に記憶しておくファイル名とユーザの識別子を組とする情報を１つ以上持つ。このようにして、リポジトリサーバ２は、あるファイルを更新するときに必ずファイル履歴を残すことが可能となる。
【００６３】
リポジトリサーバ２は、記憶媒体１６内に、２つのリポジトリ（ユーザリポジトリ２６とシステムリポジトリ２２）を有する。これらのリポジトリは、それぞれ１つ以上のファイルエントリ１００を格納し、ファイルエントリ１００は、１つのファイル名と、複数のバージョンエントリ１１０を有し、バージョンエントリ１１０は、ファイルのバージョンを一意に識別するためのバージョンＩＤ１１２と、ファイルを更新した時点での日時を表す更新日時１１４と、ファイルを更新したユーザを表す更新者１１６の識別子と、バージョンのファイルを格納しているファイル名を表すバージョン保存用ファイル名１２０と、を有する。
【００６４】
これにより、リポジトリサーバ２は、ユーザリポジトリ２６を用いて、各ユーザが独自に更新したファイルのバージョンを管理することができる。また、リポジトリサーバ２は、システムリポジトリ２２を用いて、全ユーザに共通なファイルのバージョンを管理することができる。
【００６５】
リポジトリサーバ２は、ユーザリポジトリ２６のバージョンエントリ１１０に、ファイル更新時にファイルを更新したユーザが任意の文字列を設定できる領域（更新者コメント１１８）を持つ。
【００６６】
リポジトリサーバ２は、ユーザ端末１からユーザリポジトリ２６の更新要求を受け、更新処理を行う。つまり、あるユーザが記憶媒体１６内のファイルを更新したときに、オペレーティングシステム１０は、従来のファイルをそのまま記憶媒体１６内に保存し、新規ファイルを別名で保存し、履歴管理テーブル３０のファイルに関する情報において実際に記憶しておくファイル名の情報を別名とする。
【００６７】
このユーザリポジトリ２６の更新処理を、具体的に説明する。ユーザがファイルの書き込みを要求したときに、リポジトリサーバ２は、ユーザからの書き込みを要求されたファイル名を受信し、履歴管理テーブル３０を参照してユーザの名前と書き込みを要求されたファイル名が一致したエントリを検索する。
【００６８】
まず、エントリが存在する場合は、リポジトリサーバ２は、エントリの実体ファイル名で示されるファイルを、上書きしないように別のファイル名に変えて保存し、ユーザから送信された新しいファイルを、エントリの実体ファイル名で示されるファイル名に変えて保存し、ユーザリポジトリ２６の旧バージョンのファイルに対応するエントリにおいて、バージョン保存用ファイル名１２０を前ステップで変更したファイル名に変更し、ユーザリポジトリ２６に新バージョンエントリ１１０を追記し、リポジトリサーバ２は、バージョンＩＤ１１２領域に旧ファイルのバージョンＩＤ１１２より大きい数値を持つバージョンＩＤ１１２を設定し、更新日時１１４の領域に更新が発生した日時を設定し、更新者１１６の領域に、更新を指示したユーザの識別子を設定し、更新者コメント１１８の領域に更新を指示したユーザが設定した文字列を設置し、ファイル保存用ファイル名の領域に実際に保存したファイル名を設定する。
【００６９】
一方、エントリが存在しない場合は、リポジトリサーバ２は、ユーザから送信された新しいファイルを、ディレクトリツリーに格納し、履歴管理テーブル３０に新エントリを追記し、リポジトリサーバ２は、ユーザ名の領域に書き込みを要求したユーザの識別子を設定し、ファイル名の領域に、ユーザが認識するファイル名を設定し、実体ファイル名には、ディレクトリツリーに格納したときのファイル名を設定する。
【００７０】
リポジトリサーバ２は、ユーザ端末１からユーザリポジトリ２６からシステムリポジトリ２２へのファイルの反映要求を受け、反映処理（他ユーザへの同期）を行う。つまり、ユーザがファイルの他ユーザへの同期を要求したときに、ユーザから他のユーザへの同期が要求されたファイル名を受信し、履歴管理テーブル３０中から、ユーザの名前と同期が要求されたファイル名が一致したエントリを検索する。
【００７１】
もし、エントリが存在する場合には、リポジトリサーバ２は、エントリの実体ファイル名で示されるファイルを、上書きしないように別のファイル名に変えて保存し、新規に書き込まれるファイルを、他のファイル名とファイル名が重ならない名前で保存し、旧バージョンのファイルに対応するユーザリポジトリ２６のエントリが有するバージョン保存用ファイル名１２０をファイル名に変更し、旧バージョンのファイルに対応するシステムリポジトリ２２のエントリが有するバージョン保存用ファイル名１２０をファイル名に変更し、システムリポジトリ２２に新バージョンエントリ１１０を追記する。
【００７２】
そして、リポジトリサーバ２は、バージョンＩＤ１１２領域に旧ファイルのバージョンＩＤ１１２より大きい数値を持つバージョンＩＤ１１２を設定し、更新日時１１４の領域に更新が発生した日時を設定し、更新者１１６の領域に、更新を指示したユーザの識別子を設定し、更新者コメント１１８の領域に更新を指示したユーザが設定した文字列を設置し、ファイル保存用ファイル名の領域に実際に保存したファイル名を設定する。
【００７３】
一方、エントリが存在しない場合には、リポジトリサーバ２は、ユーザから送信された新しいファイルを、ディレクトリツリーに格納し、履歴管理テーブル３０から、エントリを削除する。
【００７４】
リポジトリサーバ２は、ユーザ端末１からシステムリポジトリ２２に登録されているファイルの取得要求を受け、要求に適合するファイルを検索し、取得処理を行う。以下、取得処理の例を３つ挙げる。
【００７５】
第１の取得処理は、リポジトリサーバ２が、ユーザから取得を要求されたファイル名を受信し、履歴管理テーブル３０を参照してユーザの名前と取得を要求されたファイル名が一致したエントリを検索し、エントリが存在する場合は、エントリの実体ファイル名で示されるファイルをディレクトリツリーから取得して、その情報をユーザに返し、エントリが存在しない場合は、取得を要求されたファイル名で示されるファイルをディレクトリツリーから取得して、その情報をユーザに返す処理である。
【００７６】
第２の取得処理は、リポジトリサーバ２が、ユーザから履歴の照会が要求されたファイル名を受信し、履歴管理テーブル３０から、ユーザの名前と要求されたファイル名が一致したエントリを検索し、エントリが存在する場合は、エントリのファイル名と一致するファイル名を持つユーザリポジトリ２６のバージョンエントリ１１０全てをユーザに返信し、エントリが存在しない場合は、ユーザが要求したファイル名と一致するファイル名を持つシステムリポジトリ２２のバージョンエントリ１１０全てをユーザに返信する処理である。
【００７７】
第３の取得処理は、リポジトリサーバ２が、ユーザからのファイルの旧バージョンの内容またはその情報の要求を受けたときに、ユーザから要求されたファイル名を受信し、履歴管理テーブル３０中の全エントリから、ユーザの名前と要求されたファイル名が一致したエントリを検索し、エントリが存在する場合は、エントリに登録されたファイルに関するユーザリポジトリ２６を取得し、ユーザが要求したバージョンＩＤ１１２と一致するバージョンＩＤ１１２を持つバージョンエントリ１１０（以下バージョンエントリ１１０）をユーザリポジトリ２６またはシステムリポジトリ２２から検索し、バージョンエントリ１１０が存在するならば、バージョンエントリ１１０が持つバージョン保存用ファイル名１２０が示すファイルを、ディレクトリツリーから取得し、そのファイルの内容または情報をユーザに返信する処理である。
【００７８】
これらのリポジトリへのアクセス処理は、ＣＶＳのコマンドのように、専用のコマンドをユーザ端末１に入力させてもよいし、非特許文献１などの手法により、既存の編集ツールに埋め込むようにして、間接的にユーザ端末１に入力させてもよい。
【００７９】
以上述べた本実施形態の計算機システムによれば、ユーザはバージョン管理システムの使用方法を学習することなく、ファイル操作のみで確実に履歴を残すことが可能となる。また、あるユーザがファイルを編集中に一時的な保存を行っても他のユーザの同じファイルが新しいものに置き換わることはなく、ユーザが端末を介して反映要求を行った時点で他のユーザの同じファイルが新しいものに置き換えられる。そのため、あるユーザの一時的な保存で他のユーザの編集作業を頻繁に中断させることがなくなり、開発効率を向上することが可能となる。
【００８０】
以上説明した本発明は、以下のようにその趣旨を逸脱しない範囲で広く変形実施することができる（図１などを適宜参照）。
【００８１】
例えば、リポジトリサーバ２は、既存のディレクトリ構造上に、システムリポジトリ２２とユーザリポジトリ２６とを構成してもよい。つまり、ユーザリポジトリ２６とシステムリポジトリ２２とを１つのファイルシステム１２（１つのディレクトリツリー）に格納する構成としてもよい。
【００８２】
図１１は、１つのファイルツリーに対してシステムリポジトリ２２と複数のユーザリポジトリ２６とを割り当てたファイルシステム１２を示す構成図である。図１１（ａ）は、システムリポジトリ２２を、図１１（ｂ）は、ユーザリポジトリ２６を示す。
【００８３】
ディレクトリ“／”は、システムリポジトリ２２のルートディレクトリを示し、ディレクトリ“／．ｓｈａｄｏｗ／”は、ユーザリポジトリ２６のルートディレクトリを示す。そして、例えば、ディレクトリ“／．ｓｈａｄｏｗ／Ｘ／”をユーザＸのユーザリポジトリ２６のルートディレクトリとするように、各ユーザのユーザリポジトリ２６は、ディレクトリ“／．ｓｈａｄｏｗ／”の下に作成される。これにより、ユーザリポジトリ２６が、．（ドット）から始まる隠し属性のファイルとして作成されるので、既に稼働している既存のリポジトリシステムと衝突することがない。よって、既存のリポジトリシステムを止めることなくそのままシステムリポジトリ２２として稼働し続けることが可能となる。
【００８４】
また、リポジトリサーバ２は、最新バージョンではない、旧バージョンのファイルをバックアップするために、旧バージョンの格納先となる専用のディレクトリを作成してもよい。例えば、図１１のディレクトリ“／．ｏｌｄ／”は、システムリポジトリ２２の履歴保管用のルートディレクトリとなり、このディレクトリの下に、システムリポジトリ２２の旧バージョンのファイルが格納される。同様に、ディレクトリ“／．ｓｈａｄｏｗ／Ｘ／．ｏｌｄ／”は、ユーザＸのユーザリポジトリ２６の履歴保管用のルートディレクトリとなる。
【００８５】
図１１は、ファイルシステム１２に履歴管理機能を取り込み、ファイル操作に対応して履歴管理操作を同時に行うというものである。このとき、記憶装置に格納されるファイルは、全てのファイルの親ディレクトリであるルートディレクトリを有し、ルートディレクトリは、全てのユーザに共通なファイルを格納するためのシステムのルートディレクトリ、それぞれのユーザが独自に更新したファイルを格納するためのユーザ固有のルートディレクトリを有する。各ユーザには前記ユーザ固有のルートディレクトリと前記ユーザ固有のルートディレクトリ以下のディレクトリツリーのみを認識させることで、各ユーザが独自に更新したファイルを他のユーザに見せないようにする。この構成により、本実施形態の計算機システムは、以下の特徴を有する。
【００８６】
リポジトリサーバ２は、記憶媒体１６内に全てのファイルの親ディレクトリであるルートディレクトリを有し、ルートディレクトリは、全てのユーザに共通なファイルを格納するためのシステムのルートディレクトリと、それぞれのユーザが独自に更新したファイルを格納するためのユーザ固有のルートディレクトリとを有し、各ユーザにはユーザ固有のルートディレクトリとユーザ固有のルートディレクトリ以下のディレクトリツリーのみを認識させる。そして、ユーザ固有のルートディレクトリは、初期状態においてはシステムのルートディレクトリと同一ファイルを格納する。
【００８７】
リポジトリサーバ２は、システムのルートディレクトリ下のディレクトリツリーに格納されるファイルの更新履歴を保存するファイルシステムリポジトリを持ち、ファイルシステムリポジトリは、１つ以上のバージョンエントリ１１０を持つ。そのバージョンエントリ１１０は、図５に示すように、バージョンＩＤ１１２と、ファイルが更新された日時を記録した更新日時１１４と、更新を行ったユーザの識別子（更新者１１６）と、更新を行ったユーザが任意の文字列を設定できる領域である更新者コメント１１８の領域と、システムのルートディレクトリの保存場所を示すポインタ（バージョン保存用ファイル名１２０）を持つ。そして、バージョンエントリ１１０は、システムのルートディレクトリ下のファイルが更新されるたびに作成され、ファイルシステムリポジトリに追記される。
【００８８】
また、リポジトリサーバ２は、システムのルートディレクトリ下のディレクトリツリーに格納されるファイルの更新履歴を保存する履歴保管用のリポジトリを持つ。履歴保管用のリポジトリはルートディレクトリへのポインタと、複数のバージョンエントリ１１０からなる。バージョンエントリ１１０は、システムのルートディレクトリ中のファイルおよびディレクトリを更新した時点での日時を表す更新日時１１４、更新したユーザを表す更新者１１６の識別子、このバージョンのシステムのルートディレクトリへのポインタを持つ。
【００８９】
リポジトリサーバ２は、この履歴保管用のリポジトリを用いて、ルートディレクトリのバージョン管理を行うことができる。また、履歴保管用のリポジトリ中の、バージョンエントリ１１０はファイル更新時に当該ファイルを更新したユーザが任意の文字列を設定できる領域を持ってもよい。
【００９０】
リポジトリサーバ２は、ユーザ端末１からユーザリポジトリ２６の更新要求を受け、更新処理を行う。つまり、１人のユーザがシステムのルートディレクトリ中のあるファイルの更新を行ったとき、ファイルと、ファイルを有するディレクトリと、ディレクトリの親ディレクトリに相当するディレクトリ全てとを、ユーザ固有のルートディレクトリにコピーし、ファイルのコピーに対してファイルの更新を行う。
【００９１】
リポジトリサーバ２は、ユーザ端末１からユーザリポジトリ２６からシステムリポジトリ２２へのファイルの反映要求を受け、反映処理（他ユーザへの同期）を行う。つまり、ユーザが更新したファイルを、システムのルートディレクトリに反映させるとき、ユーザ固有のルートディレクトリを、新しいシステムのルートディレクトリとしてコピーし、前記ルートディレクトリが有するシステムのルートディレクトリを、先程作成した新しいシステムのルートディレクトリに変更し、システムリポジトリ２２に新たなバージョンエントリ１１０を作成し、オペレーティングシステム１０は、新たなバージョンエントリ１１０に対し、更新日時１１４の領域にユーザがファイルを反映した時の日時を設定し、更新者１１６の領域にファイルの反映を行ったユーザの識別子を設定し、システムのルートディレクトリの保存場所を示すポインタ領域に、変更前のシステムのルートディレクトリを設定する。
【００９２】
リポジトリサーバ２は、ユーザ端末１からシステムリポジトリ２２に登録されているファイルの取得要求を受け、要求に適合するファイルを検索し、取得処理を行う。つまり、１人のユーザが本リポジトリサーバ２にファイル名を指定して、ファイル操作命令を与えた場合に、
ステップ（１）本リポジトリサーバ２は、ルートディレクトリを参照し、さらにユーザのユーザ固有ディレクトリを参照し、
ステップ（２）本リポジトリサーバ２は、ユーザ固有のディレクトリ内のさらに下の階層のディレクトリを検索し、与えられたファイル名に一致するディレクトリを検索し、
ステップ（３）本リポジトリサーバ２は、一致するディレクトリがあった場合には、ディレクトリを参照し、
ステップ（４）本リポジトリサーバ２は、目的のファイルにたどり着くまで、ステップ（２）、（３）を繰り返す。
【００９３】
さらに、リポジトリサーバ２は、ｉノードの属性情報を拡張することにより、リポジトリを構成してもよい。具体的には、記憶媒体１６（例えば磁気ディスク）は、ファイルシステム１２が管理する、ファイルに関する情報を格納するｉノード１２０５〜１２１３を複数格納する。ｉノードは、主にＵＮＩＸ(登録商標)系のオペレーティングシステムにおけるファイル管理のための情報である。ｉノードはファイルと１対１に対応して存在し、ファイルの所有者、作成日時、属性その他の情報を格納する。ＵＮＩＸ(登録商標)系オペレーティングシステムのファイルシステムについては、文献（Daniel P. Povet、 Marco Cesati著 「Understanding the Linux Kernel、 2nd Edition」、O‘Reilly.Media.Inc）に詳しい。本実施形態ではＵＮＩＸ（登録商標）のファイルシステムを例に説明するが、他のオペレーティングシステムにおいても、同様のデータ構造によってファイルを管理しており、本発明の実施形態がＵＮＩＸ（登録商標）系オペレーティングシステムに依存しないことはいうまでもない。
【００９４】
ｉノードはファイルと１対１に存在するため、ファイルが形成するディレクトリツリーと相似な参照関係を持つ。すなわち、あるディレクトリ（ファイルシステムは、ディレクトリは特殊な属性をもつファイルとして取り扱う）に複数のファイルが格納されている場合、当該ディレクトリのｉノードには、格納されたファイルのｉノードに対するポインタが格納されている。ポインタとは、データ領域の特定の場所を指し示すためのアドレスのことである。すなわち、格納されたファイルのｉノードに対するポインタとは、データ領域の中の、ポインタが指し示す場所に、格納されたファイルのｉノードのデータが存在することを意味している。
【００９５】
図１２では、“／”ディレクトリのｉノード１２０６がディレクトリ“ｆｏｏ”のｉノード１２０９をポイントしている。これは“ｆｏｏ”ディレクトリが“／”ディレクトリに格納されていることを示す。同様にディレクトリ“ｂａｒ”も“／”ディレクトリに格納されている。さらに、“ｆｏｏ”ディレクトリのｉノード１２０９はファイル“ｆｉｌｅＡ”のｉノード１２１１をポイントしている。これは、“ｆｉｌｅＡ”が“ｆｏｏ”ディレクトリに格納されていることを示している。同様に、“ｂａｒ”ディレクトリに“ｆｉｌｅＢ”、“ｆｉｌｅＣ”が格納されていることを示している。ここまでは、従来のオペレーティングシステムのファイルシステムのデータ構造と同様である。
【００９６】
本実施形態に特有なデータ構造がルートｉノード１２０５、ユーザＸの“／”のｉノード１２０７、ユーザＹの“／”のｉノード１２０８、ファイルシステムリポジトリ１２１４がある。本発明は、ユーザ毎に仮想的なディレクトリツリーを見せることで、オペレーティングシステムが、あるユーザが行ったファイルの変更が他のユーザに反映されることを防止する技術である。したがって、ユーザごとに“／”ディレクトリを生成する必要がある。そこで、ユーザＸの“／”のｉノード１２０７、ユーザＹの“／”のｉノード１２０８をオペレーティングシステムが生成する。ユーザＸの“／”のｉノード１２０７、ユーザＹの“／”のｉノード１２０８はそれぞれ、対応するユーザが認識するディレクトリツリーに存在するディレクトリあるいはファイルのｉノードをポイントしている。
【００９７】
ユーザＸの“／”のｉノード１２０７、ユーザＹの“／”のｉノード１２０８と、“／”のｉノード１２０６がばらばらに存在すると、オペレーティングシステムは、ユーザ端末１がファイル名を与えたときに、ファイルの探索を行うことができない。そこで、前記３つのｉノードをポイントするｉノードが必要になってくる。これを本実施形態では、ルートｉノード１２０５と呼ぶことにする。
【００９８】
さらに、サーバ装置１２０１はファイルの更新履歴に関する情報を管理するためのファイルシステムリポジトリを持つ。ファイルシステムリポジトリもまたファイルであるためファイルシステムリポジトリのｉノード１２１４を持つ。
【００９９】
図１３は、ルートｉノード１２０５の構造を現す図である。ルートｉノード１２０５は、システムのルートｉノードへのポインタ１３０１、各ユーザのルートｉノードへのポインタ１３０２〜１３０４、および、ファイルシステムリポジトリｉノードへのポインタ１３０５からなる。
【０１００】
図１４は、ルート以外のｉノード１２０６〜１２１３の構造を示す図である。ルートｉノード以外のｉノード１２０６〜１２１３は、ファイル名１４０１、ファイル種別１４０２、所有者１４０３、作成日時１４０４、更新日時１４０５、属性１４０６、ポインタ１４０７〜１４０８、上位ディレクトリｉノードへのポインタ１４０９からなる。ファイル種別１４０２は、このｉノードがディレクトリであるか、一般のファイルであるかを表している。
【０１０１】
所有者１４０３は、このｉノードのオーナーである。作成日時１４０４は、このｉノードが新規に作成された時点での日時である。更新日時１４０５は、このｉノードが最後に更新された時点での日時である。ポインタ１４０７〜１４０８は、ファイル種別１４０２がディレクトリであれば、ディレクトリの中に存在するファイルｉノードへのポインタが格     納され、ファイル種別１４０２が一般のファイルであれば、ファイルの内容であるデータブロックへのポインタが格納される。上位ディレクトリｉノードへのポインタ１４０９は、このｉノードを子として持つ親ディレクトリｉノードへのポインタである。
【０１０２】
ファイルシステム１２は、ユーザ端末１からファイル名とファイル操作命令を与えられると、ルートｉノード１２０５を参照し、ポインタで示されたディレクトリを再帰的に探索して、目的のファイルのｉノードを取得する。ユーザＸがファイル操作命令をファイルシステム１２に送信した場合には、ユーザＸの“／”のポインタ１３０２を参照し、ユーザＸの“／”のｉノード１２０７を取得する。このようにして、ファイルシステム１２は個々のユーザごとに異なるディレクトリツリーを実現することができる。そして、ユーザ端末１は、ユーザごとにディレクトリツリーが異なっていることを意識することはない。
【０１０３】
図１５は、ルート以外のディレクトリｉノード１２０６〜１２１０の構造を示す図である。ファイル種別１５０１（ファイル種別１４０２に対応）は、ディレクトリであることを表す識別子が格納されている。ポインタ１５０２〜１５０３（ポインタ１４０７〜１４０８に対応）には、このディレクトリの中に存在するファイルｉノードへのポインタが格納される。
【０１０４】
図１６は、ファイルｉノード１２１１〜１２１３の構造を示す図である。ファイル種別１６０１（ファイル種別１４０２に対応）は、ファイルであることを表す識別子が格納されている。ポインタ１６０２〜１６０３（ポインタ１４０７〜１４０８に対応）には、ファイルの内容であるデータブロックへのポインタが格納される。
【０１０５】
図１７は、ファイルシステムリポジトリのｉノード１２１４の構造を示す図である。ファイルシステムリポジトリｉノード１２１４は、ファイル名１７０１、ファイル種別１７０２、所有者１７０３、ルートｉノードへのポインタ１７０４と、複数の更新履歴情報からなる。更新履歴情報は、更新日時１７０５、更新者１７０６、更新者コメント１７０７、スナップショット時の／ｉｎｏｄｅへのポインタ１７０８（上位ディレクトリｉノードへのポインタ）からなる。
【０１０６】
ファイル種別１７０２は、このｉノードがディレクトリであるか、ファイルであるかを表している。システムリポジトリ１２１４のｉノードはディレクトリなので、ファイル種別１７０２は、ディレクトリであることを表す識別子が格納されている。
【０１０７】
所有者１７０３は、このｉノードの所有者である。セキュリティの観点から、システムリポジトリｉノードのオーナーはｒｏｏｔであることが望ましい。ルートｉノードへのポインタ１７０４は、システムリポジトリｉノードの親ディレクトリであるルートｉノード１２０５へのポインタが格納される。
【０１０８】
更新日時１７０５は、ユーザ端末１が“／”のｉノード１２０６中のファイルを更新した時点での日時である。更新者１７０６は、“／”のｉノード１２０６中のファイルを更新したユーザである。更新者コメント１７０７は、“／”のｉノード１２０６のバージョンに関するテキスト情報を格納する。このテキスト情報は、更新者１７０６が示すユーザが任意に作成する。
【０１０９】
“／”のｉノードへのポインタ１７０８は、このバージョンの“／”のｉノードへのポインタが格納される。エントリ１７０５、１７０６、１７０７、１７０８が１つの組となって、当該ファイルの１つのバージョンに関する情報を記述する。ユーザ端末１がファイルを更新するたびに、ファイルシステム１２がエントリ１７０５、１７０６、１７０７、１７０８の組を追記していく。
【図面の簡単な説明】
【０１１０】
【図１】本発明の一実施形態に関する計算機システムを示す構成図である。
【図２】本発明の一実施形態に関するファイル更新処理の概要を示すフローチャートである。
【図３】本発明の一実施形態に関するファイル更新処理の概要におけるリポジトリの内容を示す説明図である。
【図４】本発明の一実施形態に関するリポジトリサーバを示す構成図である。
【図５】本発明の一実施形態に関するリポジトリのデータ構造を示す説明図である。
【図６】本発明の一実施形態に関する履歴管理テーブルの一例を示す構成図である。
【図７】本発明の一実施形態に関するユーザリポジトリの更新処理を示すフローチャートである。
【図８】本発明の一実施形態に関する履歴管理テーブルの更新の変移を示す説明図である。
【図９】本発明の一実施形態に関するシステムリポジトリの更新処理を示すフローチャートである。
【図１０】本発明の一実施形態に関するリポジトリからのファイルの検索処理を示すフローチャートである。
【図１１】本発明の一実施形態に関する１つのファイルツリーに対してシステムリポジトリと複数のユーザリポジトリとを割り当てたファイルシステムを示す構成図である。
【図１２】本発明の一実施形態に関するｉノードによるファイルシステムを示す構成図である。
【図１３】本発明の一実施形態に関するルートノードを示す構成図である。
【図１４】本発明の一実施形態に関するルート以外のノードを示す構成図である。
【図１５】本発明の一実施形態に関するルート以外のディレクトリノードを示す構成図である。
【図１６】本発明の一実施形態に関するファイルノードを示す構成図である。
【図１７】本発明の一実施形態に関するファイルシステムリポジトリを示す構成図である。
【符号の説明】
【０１１１】
１      ユーザ端末
２      リポジトリサーバ
２Ａ    開発側端末
２Ｂ    利用側端末
１０    オペレーティングシステム
１２    ファイルシステム
１４    デバイスドライバ
１６    記憶媒体
２０    ファイルデータ格納部
２２    システムリポジトリ
２４    システムリポジトリ更新部
２６    ユーザリポジトリ
２８    ユーザリポジトリ更新部
３０    履歴管理テーブル
３２    履歴管理部
３４    ユーザ認証部
１００  ファイルエントリ
１０２  ファイルＩＤ
１１０  バージョンエントリ
１１２  バージョンＩＤ
１１４  更新日時
１１６  更新者
１１８  更新者コメント
１２０  バージョン保存用ファイル名
１２２  バージョン保存用ファイル
【図１】
2006134214.tif 000003
【図２】
2006134214.tif 000004
【図３】
2006134214.tif 000005
【図４】
2006134214.tif 000006
【図５】
2006134214.tif 000007
【図６】
2006134214.tif 000008
【図７】
2006134214.tif 000009
【図８】
2006134214.tif 000010
【図９】
2006134214.tif 000011
【図１０】
2006134214.tif 000012
【図１１】
2006134214.tif 000013
【図１２】
2006134214.tif 000014
【図１３】
2006134214.tif 000015
【図１４】
2006134214.tif 000016
【図１５】
2006134214.tif 000017
【図１６】
2006134214.tif 000018
【図１７】
2006134214.tif 000019