JP2002503000A - ウェブサイトを開発するためのシステムと方法 - Google Patents

Abstract

(57)【要約】 「エリア」と呼ばれる階層的ファイルシステムで構成されたファイル管理用のシステムと方法を開示している。エリアには、ワークエリア、ステージエリア、エディションエリアの３タイプがある。ワークエリアは修正可能なファイルエリアで、このエリアでユーザはファイル及びディレクトリの作成、編集、削除を行うことができる。ステージエリアは、選択されたバージョンオペレーションをサポートする読み出し専用ファイルシステムである。ワークエリアの様々なユーザは、自分達のワークエリアのコンテンツをステージエリアに提出することによって、自分達のワークを統合化できる。ステージエリアで、開発者は、自分達のワークを比較し、自分達の変更がどう適合するかを知ることができる。エディションエリアは読み出し専用ファイルシステムであり、ステージエリアのコンテンツの固定された読み出し専用のスナップショットが生成するために、ステージエリアのコンテンツが仮想的にコピーされエディションとなる。ファイル管理のためのシステムと方法の１つの使い方として、ウェブサイト開発ツールとしての使い方が挙げられる。

Description

【発明の詳細な説明】

【０００１】 （関連出願） 本出願は、1９９８年２月４日付けの米国特許出願番号第６０／０７３，７６ ６号、「ウェブサイトを開発するためのシステムと方法」の内容を本明細書に完
全に開示された参考文献として援用する。 （発明の属する技術分野） 本発明は一般的には階層的ファイルシステムに関する。より厳密には、ウェブ
サイトを開発するツールとして使用できる、ファイル管理のためのシステムと方
法に関する。

【０００２】 （先行技術） インタネットは商業的に大きな役割を果たしており、多くの会社がウェブサイ
トを所有する傾向にある。多くのウェブサイトはしばしば修正する必要があり、
通常は数十人のコントリビュータの手で特別なプロセスによって修正される。そ
れ故、ウェブサイトのコンテンツを更新し、正確にし、良好に統合された状態に
維持するための継続的プロセスは、初期計画及び開発のフェーズでのプロセスよ
りもしばしば大きな課題となる。インタネットは数百にも及ぶチームによって、
日毎、時間毎、又は分毎に更新される。同様に、イントラネットのコンテンツの
コントリビュータは新たなコンテンツを絶えず提出したり又は既存コンテンツに
変更したりするので、新たなコンテンツを素早く組み込まないと、基本的な通信
リソースとしてのイントラネットの有用性は限定されてしまう。

【０００３】 大型ウェブサイトは、ウェブコントリビュータの数が指数的に増加すると、多
くの問題に直面する。これらのサイトの規模とコンテンツは急速に増加しつづけ
ており、サイトの通信量とインタネット商取引が増えるにつれ、より頻繁な更新
が必要となる。コントリビュータ、量、コンテンツの複雑さが増すにつれ、各変
更を監督し品質を管理することはウェブサイトの管理者（「ウェブマスタ」）に
とってますます困難となるに至った。 ウェブサイトの開発は複雑なので、ウェブサイト開発を監督／管理する中央シ
ステムが必要となる。ウェブサイトの開発を監督／管理するための既存のシステ
ムには、ソフトウェア構成監督システム、ドキュメント監督システム、データベ
ース発行システムが含まれている。

【０００４】 このような既存のウェブサイト開発システムには、不利な点が幾つかある。例
えば、ウェブサイトを維持するには数十人又は数百人の手を煩わすことが必要な
ので、ウェブサイトコントリビュータを並列に作業させることが望ましい。ソフ
トウェア構成監督システムは、複数のコントリビュータがウェブサイトの同一エ
リアを変更することを許さない。更に、既存のシステムでは何れも、並行に作業
するコントリビュータがウェブサイトを実際に変更することなく自分の作業を別
々にテストすることを許さない。従って、矛盾する変更がウェブサイトに寄せら
れ、ウェブサイトにエラーを生じさせることもある。

【０００５】 コントリビュータは自分の作業が他のコントリビュータの作業と組み合わされ
た際にどんな影響があるのか個別のレベルで予測することができないので、既知
のシステムでは、ウェブマスタがウェブサイトに寄せられた全ての変更点を統合
してエラーをチェックすることに依存している。ウェブマスタは又、変更を認め
られたコントリビュータがコンテンツを変更することを保証している。しかし、
ウェブマスタは、ウェブサイトの変更に関する統合と試験を全て行わねばならな
いので、しばしばウェブサイトを開発するプロセスのボトルネックとなる。複数
のユーザの作業を統合することは人手を介してなされ時間も掛かり、バグの判定
及び矛盾点の解決に膨大な時間が浪費されるのに対し、システムの設計、改革、
戦略には殆ど時間が掛けられていない。更にウェブマスタは、コントリビュータ
が変更点をウェブマスタへ提出する準備が整うまで、コントリビュータの変更の
進展度合を容易には監督することができない。従って、ウェブマスタは、早い段
階でエラーを正すこともできなければ、コントリビュータがどの位進展している
かを判定することもできない。

【０００６】 既知のウェブサイト開発システムの別の欠点は、ファイルバージョンの履歴を
追跡しない点である。ウェブサイトのファイルは常に追加、除去、変更、移動、
再命名されているので、誰がどんなファイルバージョンを作ったか、バージョン
は何時作られたかを知ることが有効である。以前のバージョンへ完全にアクセス
することにより、ユーザは、バグを生じさせた変更を容易に見つけ、過去のバー
ジョンに立ち戻り、新たなバグを特定することができる。更に、既知のウェブサ
イト開発システムでは、サイトの一部又は全体についての如何なる過去のバージ
ョンへも直接アクセスすることができない。ウェブサイトの任意の過去のバージ
ョンへ直接立ち戻れることは、サイトエラーが起きたり又は不適切又は不正確な
情報が配分されたりした場合に惨事から回復するための不可欠なツールとなる。

【０００７】 従って、ウェブサイトを実際に変更することなく、変更点がウェブサイト全体
の中でどう適合するかをコントリビュータが決められるウェブサイト開発システ
ムが求められている。更に、コントリビュータがファイルの初期バージョン、ウ
ェブサイトのサブセクション又はウェブサイトへアクセスでき、且つ、ウェブマ
スタがウェブサイトをより容易に変更できると同時にコントリビュータの進展状
況をチェックできるウェブサイト開発システムが求められている。

【０００８】 （発明の概要） 本発明は、ファイル管理のためのシステムと方法を提供する。このようなシス
テムの１つの使い方は、ウェブサイト開発ツールとしての使い方である。 本発明のシステムは、本明細書で「エリア」と呼ばれる階層的ファイルシステ
ムで構成される。エリアには、ワークエリア、ステージエリア、エディションエ
リアの３タイプがある。ワークエリアは修正可能なファイルシステムエリアであ
り、このワークエリアでユーザは、ファイル及びディレクトリの作成、編集、削
除、追加，修正を行うことができる。１実施例では、ワークエリアは既存ウェブ
サイトの仮想的なコピーであり、ウェブサイトに関するユーザの個人的見解であ
る。

【０００９】 ステージエリアは、選択されたバージョン化オペレーションをサポートする読
み出し専用ファイルシステムである。ワークエリアの様々なユーザは、自分達の
ワークエリアのコンテンツをステージエリアに提出することによって、自分達の
ワークを統合化することができる。ステージエリアにおいて、開発者は、自分達
のワークを比較し、自分達の変更点がどのように適合しているかを知ることがで
きる。

【００１０】 エディションエリアは読み出し専用ファイルシステムである。ステージエリア
のコンテンツは仮想的にエディションエリアへコピーされ、ステージエリアのコ
ンテンツの固定された読み出し専用のスナップショットが生成される。１実施例
では、エディションエリアのコンテンツは、ウェブサイトのエディションのコン
テンツを表す。

【００１１】 １実施例では、複数のエリアはディレクトリツリーを共有し、エリアが作成さ
れる毎にディレクトリ及びファイルを物理的にコピーする必要はない。これによ
り、エリアを素早く作成することができ、システムリソースを有効に利用できる
。ファイル又はディレクトリのコンテンツに関する情報を記憶する履歴オブジェ
クトは、ファイル又はディレクトリが存在する各エリア中の各ファイル又はディ
レクトリと関係付けられている。

【００１２】 別の実施例では、本発明は各ファイル及びディレクトリのコンテンツの履歴を
追跡する。これにより、システムはファイル同志を又はディレクトリ同志を容易
に比べることができ、それらが同一なのか又は関係付けられているのかを識別す
ることができる。 更に別の実施例では、本発明のシステムは、１つのウェブサーバを複数のウェ
ブサーバであるかのように作動させることのできるＨＴＴＰプロトコルバーチャ
ライゼーションモジュールを含んでいる。これにより、各エリアはエリア毎に個
別のウェブサーバを持つことなく、ＨＴＴＰプロトコルレベルにおける完全なウ
ェブサイトになることができる。

【００１３】 （実施例） 本発明をウェブサイト開発と関連付けて以下に説明するが、当該技術分野に詳
しい当業者に理解されているように、本発明は他の具体的な形でも実現すること
ができる。

【００１４】 図１は、ウェブサイト開発用のコンピュータネットワーク１００を示す。従来
型のパソコンである開発ワークステーション１１０上で、ウェブサイト開発者は
ウェブサイト用のファイルを追加し、除去し、編集し、検査する。開発ワークス
テーション１１０は、インタネットのようなコンピュータネットワーク１２０を
介して開発サーバ１３０に接続される。 開発サーバ１３０は、ウェブサイトコンテンツを求める開発ワークステーショ
ン１１０からのＨＴＴＰ要求を処理するウェブサーバ１４５を含んでいる。開発
サーバ１３０は、マイクロソフト社から商業的に入手可能なウインドウズＮＴフ
ァイルシステムのような従来型の支援記憶装置１６０も含んでおり、ここにＷＳ
ファイルが物理的に記憶されている。

【００１５】 開発サーバ１３０は、ウェブサイト開発ソフトウェアモジュール１３５を実行
することによって本発明のウェブサイト開発方法を実現する従来型のメモリ１５
０（即ち、ＲＡＭ）及び従来型プロセッサも含んでいる。以下に述べるウェブサ
イト開発モジュールはメモリ１５０に記憶される。メモリ1５０には、ウェブサ ーバ１４５を複数のウェブサーバの如く作動させる以下に述べるＨＴＴＰプロト
コルバーチャライゼーションモジュール１３７も記憶されている。

【００１６】 開発サーバ１３０は、ネットワーク１６５を介してプロダクションウェブサー
バ１７０に連結される。ネットワーク１６５はネットワーク１２０のような同じ
ネットワークでも、別のネットワークでもよい。ウェブサイトプロダクションウ
ェブサーバ１７０はインタネット又はイントラネット１７５へ連結されており、
あるウェブサイトをワールドワイドウェブ又はイントラネットへ通知する準備が
整うと、開発サーバ１３０は当該ウェブサイトをプロダクションウェブサーバ１
７０へ送り、プロダクションウェブサーバ１７０は、インタネット又はイントラ
ネットへのアクセスを当該ウェブサイトへ提供する。

【００１７】 ウェブサイトは任意のファイルシステムのコンテンツで構成される。本発明の
ウェブサイト開発システムは階層的ファイルシステムの集合から構成される。こ
れらファイルシステムのそれぞれは、個別のファイルを管理する環境であり、個
別ファイルを操作するための手段を提供する。実行時に、ウェブサイト開発ソフ
トウェアモジュール１３５は、ファイルの管理と操作の大部分を行うことのでき
るファイルシステムの一部となる。支援記憶装置１６０には、ファイル及び対応
するメタデータ（即ち、オーナーＩＤ、グループＩＤ、アクセスコントロールフ
ァイル名、修正回数、作成回数等）が物理的に記憶される。１実施例では、ファ
イルは（支援記憶装置１６０中に物理的に記憶されていても）支援記憶装置１６
０以外のドライブに記憶されているように見えるようにすることができる。

【００１８】 階層的ファイルシステムは、ファイルとシンボルリンクを有するディレクトリ
ツリーを備えている。ディレクトリツリーの頂点にはルートディレクトリが存在
し、ここから他の全てのディレクトリが直接的に又は間接的に派生する。 ファイルシステムは、修正可能システム又は読み出し専用システムである。修
正可能ファイルシステムは、ファイル上の読み出しオペレーション（即ち、ルー
トディレクトリ取得、ディレクトリ読み出し、ディレクトリ参照、ファイル読み
出し、属性取得、シンボルリンク読み出し等）をサポートし、オペレーション（
即ち、ディレクトリ作成、ファイル作成、シンボルリンク作成、属性セット、フ
ァイル除去、ディレクトリ除去、ファイル再命名、ディレクトリ再命名、ファイ
ル書込等）を修正するファイルシステムである。

【００１９】 読み出し専用ファイルシステムは、読み出しオペレーションのみを支援する。
読み出し専用ファイルシステムとしては、ＣＤＲＯＭボリュームと、書き込みタ
ブがライトプロテクト位置にあるフロッピーディスクボリュームとの２つの例を
挙げることができる。

【００２０】 上記のように、本発明のウェブサイト開発システムは階層的ファイルシステム
から構成される。階層的ファイルシステムの幾つかは、ウェブサイトのコンテン
ツを構成するファイルを生成するように修正することができる。他のファルシス
テムは、ウェブサイト開発に協調させるために他のファルシステムからのファイ
ルを比較することができ、更に別のファルシステムは、ウェブサイトのコンテン
ツを構成する完成したファイルを含んでいる。

【００２１】 本発明の階層的ファイルシステムが従来のファイルシステムと異なる１つの点
は、読み出し及び／又は修正オペレ−ションに加えて、本発明のファイルシステ
ムの幾つかが、以下に述べるように２つ又はそれ以上の関係ファイルシステムを
操作できる選択されたバージョン化オペレーションをサポートする点である。ウ
ェブサイトのコンテンツは、本発明の関連ファイルシステムの集合上で読み出し
オペレーション、修正オペレーション、バージョン化オペレーションを実行する
ことにより作成される。

【００２２】 本発明の階層的ファイルシステムは「エリア」と呼ばれ、ワークエリア、ステ
ージエリア、エディションエリアの３タイプのエリアがある。ワークエリアは、
修正可能なファイルシステムであるが、ステージエリアとエディションエリアは
読み出し専用ファイルシステムである。

【００２３】 ワークエリアは、既存のウェブサイトの仮想的なコピーとして始まる（既存シ
ステムが存在しない場合を除く。存在しない場合、ワークエリアは空の状態から
始まる）。換言すると、ワークエリアは、ウェブサイトとして指定されたファイ
ルシステムと同じコンテンツを有して始まる。ワークエリアは、ウェブサイトに
関する開発者の個人的な見解であり、ウェブサイトに寄稿する各開発者はワーク
エリアへ寄稿をしているのである。ワークエリア中で、開発者はウェブサイトコ
ンテンツを自由に追加、削除、修正することができ、自分の変更がウェブサイト
全体のコンテキスト中でどう適合するかを知ることができる。追加、削除、修正
のオペレーションの詳細を以下に述べる。あるコントリビュータがあるワークエ
リアで行った変更は、他のコントリビュータが他のワークエリアで行ったワーク
には影響しない。これは、以下に述べるように各エリアが別のファイルシステム
となっているからである。

【００２４】 開発者は、自分達のワークエリアのコンテンツをステージエリアへ提出するこ
とにより、自分達のワークをステージエリアで統合する。提出オペレーションと
は、上記の選択されたバージョン化オペレーションの1つであり、以下に更に詳 しく述べる。ステージエリアは、ブランチ（ブランチは以下に詳述）上の全ユー
ザが入手できるウェブサイトに関する共有の見解である。換言すると、ステージ
エリアは、ブランチに沿って全ユーザがアクセスすることができるファイルシス
テムである。ステージエリアは、複数の開発者のワークエリアの集合的ワークエ
リアを保持し、このステージエリアによって開発者は自分達の変更を共有し統合
化することができる。ステージエリアにおいて、開発者は自分達のワークを比較
し、自分達の変更がどのように適合するかを知ることができる。比較オペレーシ
ョンは、以下に詳述する選択されたバージョン化オペレーションの別のオペレー
ションである。

【００２５】 ステージエリアにおける集合的ワークは、別のコントリビュータがワークエリ
アから新たなコンテンツを提出するにつれて変化するステージエリアの現状態に
ワークエリアを更新するために、個人のワークエリアへ仮想的にコピーし直すこ
とができる。エリアはディレクトリツリーを共有し、ディレクトリツリーを物理
的にコピーする必要がないようになっているので、コピーは「仮想的」である。
ステージエリアにおける集合的ワークが最終的なものと見なされると、そのコン
テンツが発行されウェブサイトのエディションが作成される。 エディションからワークエリアを作成する段階と、ステージエリアを発行する
段階とは、以下に述べる選択されたバージョン化オペレーションの追加オペレー
ションである。

【００２６】 ステージエリアのコンテンツは、エディションエリアへ仮想的にコピーされ、
ウェブサイトのエディションが作成される。ここでも仮想的コピーは、エディシ
ョンがステージエリアの場合のように同じディレクトリツリーを参照することを
意味している。エディションは読み出し専用ファイルシステムであるので、エデ
ィションは、単一ブランチに沿った特定の点におけるウェブサイト全体のコンテ
ンツの固定されたスナップショットである。各エディションは記録され全開発者
がアクセスできる。

【００２７】 エディションのコンテンツはワークエリアへ仮想的にコピーし直すことが可能
で、ウェブサイトを更に開発するベースとして使うことができる。エディション
は又、記録としての役割を果たし、ユーザはファイルやディレクトリを瞬間的に
呼び戻し、ウェブサイトの過去の全バージョンを再構成することができる。

【００２８】 図２は本発明のある開発者の視点から見たワークエリアからエディションまで
の開発フローを要約したものである。開発者は段階２１０において、ワークエリ
アでファイルを編集、追加、削除する。次に開発者は段階２２０において、自分
のワークエリアのコンテンツをステージエリアへ提出する。ステージエリアで、
コントリビュータのワークエリアのコンテンツは段階２３０において、他のコン
トリビュータのワークエリアのコンテンツと統合される。段階２４０において、
ステージエリアへ提出された全てのコンテンツが良好に統合され承認されると、
ステージエリアのコンテンツは段階２５０において、エディションとして発行さ
れる。発行されなければ、コントリビュータは、自分のファイルが承認されるま
で、段階２１０において編集を継続する。

【００２９】 １実施例によれば、ウェブサイト開発は開発の幾つかのブランチに沿って分割
することができる。開発者の視点からすると、ブランチとは単一のウェブサイト
の開発経路である。図３に示すように、単一のブランチ３００は、ワークエリア
３１０、ステージエリア３２０、１つ又はそれ以上の記録されたウェブサイトエ
ディション３３０を含んでいる。ブランチは、開発チームが互いに別の代わりの
開発パスを保持できるように、サブブランチを含むことができる。コンテンツは
ブランチ、サブブランチの間で共有することができる。 ウェブサイト開発をブランチに沿って分割するある例では、現在のウェブサイ
トのために１つのブランチを有し且つウェブサイトの新たなバージョンのために
別のブランチを有している。別の例では、特定の領域又はクライアント用にウェ
ブサイトを誂えるために、別の領域又は別のクライアントのために別の開発ブラ
ンチを有している。

【００３０】 ウェブサイト開発ソフトウェアモジュールが開発サーバにインストールされた
時に、メインブランチは生成される。図４に示すように、メインブランチ４００
は最初、空のステージエリア４２０と空のエディション４３０とを含む。メイン
ブランチは最初、空のワークエリア４１０も含んでいる。ワークエリアは、メイ
ンブランチが作成される時、又は、ワークエリアの属性を定義する準備が整うま
でワークエリアの生成を遅らせたいとユーザが思う暫く後の時（人々がワークエ
リアへアクセスできる時）に生成することができる。

【００３１】 ウェブサイト開発ソフトウェアモジュール以前から存在していたウェブサイト
がインストールされる場合、ワークエリアが事前に存在していなければ、空のワ
ークエリア４１０が生成される。図５に示すように、元のウェブサイトのコンテ
ンツ５１０は、空のワークエリア４１０へコピーされ、次に空のステージエリア
４２０へコピーされ、次に初期エディション４４０へ発行される。

【００３２】 追加のワークエリアは、最も新しいエディションのコンテンツを新たなワーク
エリアへ仮想的にコピーすることにより、メインブランチとは別の形で作成する
ことができる。図６は、エディション４４０からメインブランチ上に３個のワー
クエリア６００が生成されることを示す。ワークエリア６００のコンテンツはス
テージエリア６１０へ提出され、ステージエリア６１０のコンテンツは新たなエ
ディション６２０へ発行される。

【００３３】 サブブランチも又、メインブランチ又は他のブランチと別の形で作成すること
ができる。図７はサブブランチがメインブランチと別の形で作成されることを示
す。親ブランチ７２０からのエディション７１０が、サブブランチ７３０用の初
期エディション７２５として使われる。初期エディション７２５のコンテンツは
次に、ワークエリア７４０、ステージエリア７５０、サブブランチ７３０の新た
なエディション７６０へと、仮想的にコピーされる。サブブランチは他のサブブ
ランチと別の形で同様に作成できることに注目されたい。サブブランチ上でのワ
ークは、高次のブランチ上でのワークと並行且つ独立に起こる。

【００３４】 サブブランチ上で生成されたワークは、サブブランチ上のエディションのコン
テンツを高次ブランチ上のワークエリアへ仮想的にコピーすることにより、高次
レベルのブランチへ組み込むことができる。サブブランチからのコンテンツは、
他のワークエリアからのコンテンツと統合され、高次のブランチの新たなエディ
ションとして発行される。 ウェブサイト開発システムの概要と代表的な使い方を述べたので、１実施例に
よるシステムの具体的な実行について述べる。

【００３５】 各々の独立したワークエリア、ステージエリア、エディションエリアは、ツリ
ー構造に組織化された１つ又はそれ以上のファイル及びディレクトリから構成さ
れる。図８は、ディレクトリ１をルートディレクトリとしたエリアのディレクト
リの例を示す。エリアは同じディレクトリツリーを共有することができる。実際
に、既存エリアがコピーされて新たなエリアが作られる場合、新たなエリアは、
既存エリアとしての同じルートディレクトリを参照するだけである。

【００３６】 各々の独立したワークエリア、ステージエリア、エディションエリアは、エリ
アを表し、且つ、ネームフィールド、オブジェクトＩＤフィールド、世代ＩＤフ
ィールド、ディレクトリフィールド、ブランチフィールドを有するオブジェクト
を生成することによって、生成される。ネームフィールドは、ワークエリアの名
前を含んでいる。ディレクトリフィールドは、特定のワークエリア、ステージエ
リア、エディションエリアのディレクトリツリーのルートディレクトリを識別す
る。ブランチフィールドは、ワークエリアがどのブランチに沿って存在するかを
表す。図９はワークエリアオブジェクトの図形的に表したものである。ワークエ
リアを生成する際、ワークエリアオブジェクトが既存のディレクトリツリーを指
示するので、ディレクトリツリーの仮想コピーは実際のコピーに相対するものと
して作られることに注目されたい。

【００３７】 各々のワークエリア、ステージエリア、エディションエリアは、２つの固有の
識別子を有し、本アプリケーションでは一方を「世代ＩＤ」、他方を「オブジェ
クトＩＤ」と呼ぶ。オブジェクトＩＤはエリアを表すオブジェクトを識別し、一
旦オブジェクトＩＤがあるオブジェクトに割り当てられると、このオブジェクト
ＩＤは変更されることがない。各エリアは又、あるエリアが他のエリアとどのよ
うに関連しているかを示す固有の世代ＩＤによっても識別される。特定のエリア
の世代ＩＤは、以下に述べるように（例えば、ステージエリアがエディションへ
発行される時）変更することができる。世代ＩＤは世代ＩＤフィールドに配置さ
れている。オブジェクトＩＤはオブジェクトＩＤフィールドに配置されている。

【００３８】 ディレクトリ、ファイル、履歴オブジェクト（以下に述べる）、及び他のオブ
ジェクトにも、一旦割り当てられると変更されることのないオブジェクトＩＤが
割り当てられることに注目されたい。 世代ＩＤは、数字からなる固有のシーケンス又はセットから構成される。世代
ＩＤは、エリアを固有に識別するだけでなく、上記のように、あるエリアが他の
エリアとどのように関連しているかを示す。

【００３９】 エリアの1つが直接又は間接に他のエリアから派生している場合、あるエリア は別のエリアに関係している。例えば、図７において、サブブランチの初期エデ
ィションは、親ブランチのエディション２から直接派生している。サブブランチ
のワークエリアは、サブブランチの初期エディションから直接派生し、親ブラン
チのエディション２から間接的に派生している。 世代ＩＤは、世代ＩＤに固有な番号と、世代ＩＤを派生する世代ＩＤの数字と
を含んでいる。例えば、番号１があるエリアへ割り当てられた固有番号で、番号
０が別のエリアへ割り当てられた固有番号である場合、これらのエリアから派生
されたあるエリアの世代ＩＤは、番号０と１と同様に例えば、自身の固有番号例
えば４である。

【００４０】 図１０は、親世代ＩＤが新たなエリアの直接の親へ割り当てられる場合につい
て、親世代ＩＤから新たなエリアへ割り当てられる世代ＩＤを派生するための方
法を示す。ある固有番号が段階１０００において、連続的に（例えば、１、２、
３、４）又は無作為に数字を生成するための従来のアルゴリズムを使って得られ
る。次に、親世代ＩＤに関連する固有数字のセット又はシーケンスが段階１０１
０において検索される。次いで、親世代ＩＤと丁度今発行された固有番号を連結
する数字のセット又はシーケンスが、段階１０２０で生成される。

【００４１】 エリア間の関係も系図ツリーで表される。系図ツリーはデータ構造であり、ツ
リーの各ノードは異なる世代を表している（例：エリア。本アプリケーションエ
リアを通じてエリアをしばしば世代と呼んでいることに注意されたい）。

【００４２】 図11は系図ツリーの例を表している。世代Ｇ０は初期エディションを表す。世
代Ｇ２はあるワークエリア（「ワークエリア１」）を表し、世代Ｇ３は別のワー
クエリア（「ワークエリア２」）を表し、世代Ｇ１はあるエディション（「エデ
ィション１」）を表し、世代Ｇ４はステージエリアを表している。系図ツリーは
Ｇ１、Ｇ２、Ｇ３がＧ０から直接派生されたことを示し、これはＧ１、Ｇ２、Ｇ
３がＧ０として同一のルートディレクトリを有することを意味する。Ｇ４はＧ０
から間接的に派生され、Ｇ１から直接的に派生されており、それ故にＧ０として
同一のルートディレクトリを有する。

【００４３】 図１２はディレクトリ１２００を図形的に表示している。ディレクトリが変更
された世代毎に、ディレクトリは世代ページ１２８０を含んでおり、この世代ペ
ージ１２８０は、世代ページ１２８０に対応する世代でのディレクトリコンテン
ツを掲げるオブジェクトである。従ってディレクトリは、ディレクトリが変更さ
れた各世代におけるディレクトリコンテンツのスナップショットを含んでいる。
たとえディレクトリが別のエリアに別のコンテンツを有していても、世代ページ
１２８０により別のエリアは同じディレクトリを参照することができる。

【００４４】 図１２に示したディレクトリ１２００で、ディレクトリページ１２８０は、ア
イテム「ｍ」が世代Ｇ０でディレクトリ１２００へ加えられたこと、アイテム「
ｎ」が世代Ｇ２でディレクトリ１２００へ加えられたこと、アイテム「ｐ」が世
代Ｇ３でディレクトリ１２００へ加えられたことを示している。如何なるものも
ディレクトリ１２００から除去されなかったと仮定すると、ディレクトリページ
１２８０は、特定の世代で加えられたコンテンツを含むだけでなく、特定の世代
から派生された世代で加えられたコンテンツも含んでいる。例えば、図１０の系
図ツリーをこの例に当てはめるとしよう。世代Ｇ０において、ディレクトリｄ１
はアイテム「ｍ」を含んでいる。世代Ｇ２において、アイテム「ｎ」がディレク
トリ１２００に加えられており、従って、Ｇ２はＧ０から派生しているので、デ
ィレクトリ１２００は世代Ｇ２において、アイテム「ｍ」と「ｎ」を含んでいる
（「ｍ」は除去されてないと仮定する）。世代Ｇ３において、アイテム「ｐ」が
ディレクトリｄ１に加えられるので、ディレクトリ１２００はアイテム「ｐ」と
「ｍ」を含んでいる。Ｇ３はＧ２から派生されたのではないので、結果的にディ
レクトリ１２００は世代Ｇ３において、アイテム「ｎ」を含んでいない。

【００４５】 １実施例では、ディレクトリが特定の世代で変更されてない場合、当該ディレ
クトリは当該世代の世代ページを含まないことになる。ディレクトリはある世代
で変更されると、当該世代に関する世代ページがディレクトリへ加えられる。

【００４６】 ディレクトリ中の各アイテムは履歴オブジェクトに関係している。履歴オブジ
ェクトは、ファイル又はディレクトリのコンテンツが編集又は修正された世代を
示す。換言すると、履歴オブジェクトはディレクトリ中におけるアイテムの履歴
を示している。履歴オブジェクトは、世代ＩＤのフィールド１２２５と、ファイ
ル又はディレクトリへのポインタのコンテンツフィールド１２３０とを含んでい
る。図１２に示した例では、履歴オブジェクトｈ０は、世代ｇ０においてアイテ
ムｎがファイルｆ１に関係するコンテンツを含んでいることを示す。履歴オブジ
ェクトｈ０は又、世代Ｇ２においてアイテムｎがファイルｆ２（ファイルｆ１で
はなく）に関係するコンテンツを含んでいることを示す。コンテンツフィールド
１２３０に掲げられたアイテムは、ファイルｆ２の実際のコンテンツを指してい
る。ｆ２がディレクトリであったとすると、ｆ２はディレクトリ１２００のよう
な別のディレクトリを指すことになろう。コンテンツには、ディレクトリに掲げ
られたアイテムに関係して先行するファイル又はディレクトリへのポインタを有
する「以前のフィールド」１２４０が含まれている。例えば、ｆ２は、ｆ１への
ポインタ１２４０と同時に、世代Ｇ２に先行してアイテム「ｍ」がｆ１のコンテ
ンツを有していたことを意味するコンテンツ「Ｂ」を有するファイルを指す。

【００４７】 図１３は、ワークエリア、ステージエリア、エディションエリアの生成と操作
を可能にする本発明の１実施例によるウェブサイト開発ソフトウェアモジュール
１３５を示す。ウェブサイト開発ソフトウェアモジュール１３５は、ワークフロ
ーサブシステム１３００、バージョン化サブシステム１３０５、オブジェクトサ
ブシステム１３１０を含んでいる。ワークフローサブシステムは、ワークエリア
、ステージエリア、エディションエリア、ブランチを生成し管理する。バージョ
ン化サブシステムは、ファイル及びディレクトリの修正及び編集、ファイルの比
較、ディレクトリの比較、ワークエリアのコンテンツのステージエリアへの提出
、矛盾点に関するファイル及びディレクトリの照合等の機能を管理して制御する
。オブジェクトサブシステムは、サーバのメインメモリ中及びディスク中におけ
るオブジェクトの配分を管理する。オブジェクトサブシステムは、従来継続型の
オブジェクト記憶及びキャッシュサブシステムとして実行されてもよい。

【００４８】 ワークフローサブシステムはワークエリア生成モジュール１３１２、ステージ
エリア生成モジュール１３１４、エディションエリア生成モジュール１３１６、
ブランチ生成モジュール１３４６、エリア削除モジュール１３４２を含む。バー
ジョン化サブシステム１３０５は、提出モジュール１３３６、矛盾照合モジュー
ル１３３８、比較モジュール１３４０、追加アイテムモジュール１３１８、参照
カウントモジュール１３２０、追加直接参照モジュール１３２２、取り除き直接
参照モジュール１３２４、読み出しディレクトリモジュール１３２６、取り除き
アイテムモジュール１３２８、エディットファイルモジュール１３３０、再命名
モジュール１３３２、世代ディレクトリ経路モジュール１３３４、ロックモジュ
ール１３４４、世代ＩＤモジュール１３４８を含んでいる。ワークフローサブシ
ステム及びバージョン化サブシステムのこれらのモジュールによって、エリア、
ファイル、ディレクトリ、及びウェブサイト開発に使われる他のオブジェクトの
作成と操作ができるようになる。

【００４９】 ワークフローサブシステム及びバージョン化サブシステムは、Ｃ＋＋プログラ
ミング言語で実行される。ワークフローサブシステム及びバージョン化サブシス
テムのモジュールのオペレーションを以下に述べる。 上記のようにワークエリアは、以前のエディションのコンテンツをワークエリ
アへ仮想的にコピーすることによって作成される（メインブランチ上の最初のワ
ークエリアが初期において空状態にある場合は例外とする）。図１４は、任意に
「エディションｅ」と名付けられたあるエディションからワークエリアを作成す
るためのワークエリア生成モジュール１３１２のオペレーションを示す。モジュ
ール１３１２は段階１４１０において、ルートディレクトリとエディションｅの
世代ＩＤとを取得する。次に、モジュール１３１２は段階１４２０において、世
代ＩＤモジュール１３４８から新たな世代ＩＤを取得するが、このＩＤはエディ
ションｅの世代ＩＤから派生されたものである。世代ＩＤモジュール１３４８は
新たな世代ＩＤを、図１１に示したプロセスを実行することにより派生する。モ
ジュール１３１２は又、ワークエリア用の新たなオブジェクトＩＤ（無作為又は
連続的に生成された固有の数）も取得する

【００５０】 モジュール１３１２は段階１４３０において、ワークエリアを表し且つネーム
フィールド、ルートディレクトリフィールド、オブジェクトＩＤフィールド、世
代ＩＤフィールド、ブランチフィールドを有するオブジェクトを作成する。モジ
ュール１３１２は段階１４４０で、ワークエリアの名前をネームフィールドへ、
エディションｅのルートディレクトリをルートディレクトリフィールドへ、段階
１４２０で派生された世代ＩＤを世代ＩＤフィールドへ、オブジェクトＩＤをオ
ブジェクトＩＤフィールドへ、ワークエリアが存在するブランチＩＤをブランチ
フィールドへ入れる。こうしてオブジェクトは、ワークエリアが、エディション
ｅの同じルートディレクトリを有し且つ派生された世代ＩＤを有するデータ構造
であることを示す。ワークエリアを作成するためにエディションｅのコンテンツ
が物理的にコピーされているのではないことに注目されたい。むしろ、新たに作
成されたワークエリアは初期にはエディションｅと同じデータ構造を有している
ことを示すオブジェクトが作成されたのである。

【００５１】 図１５は、エディションｅと呼ばれるエディションからステージエリアを作成
するためのステージエリア生成モジュール１３１４のオペレーションを示す。ス
テージエリアを作成するため、モジュール１３１４は段階１５１０において、エ
ディションｅの世代ＩＤを取得し、次に段階１５２０において、エディションｅ
の世代ＩＤから派生された新たな世代ＩＤを世代ＩＤモジュール１３４８から取
得する。モジュール１３１４は又、ステージエリアのための新たなオブジェクト
ＩＤ（無作為又は連続的に生成された固有の数）も取得する。

【００５２】 モジュール１３１４は、ステージエリアを表し且つネームフィールド、ルート
ディレクトリフィールド、世代ＩＤフィールド、オブジェクトＩＤフィールド、
ブランチフィールドを有するオブジェクトを作成する。モジュール１３１４は段
階１５４０において、ステージエリアの名前をネームフィールドへ、エディショ
ンｅのルートディレクトリをルートディレクトリフィールドへ、段階１５２０で
得られた世代ＩＤを世代ＩＤフィールドへ、段階１５２５で得られたオブジェク
トＩＤをオブジェクトＩＤフィールドへ、ステージエリアが存在するブランチＩ
Ｄをブランチフィールドへ入れる。

【００５３】 複数のステージエリアを有することの望ましいことが時にはある。例えば、公
のステージエリアに加えて、選ばれたユーザのみがコンテンツを提出できる数個
の私的なステージエリアを有することが望ましい。複数のステージエリアは、上
記のステージエリア作成方法を複数回実行することによって作成することができ
る。

【００５４】 図１６ａ−ｂは、任意に「ｓ」とラベル付けされたステージエリアのコンテン
ツからエディションを作成するためのエディションエリア生成モジュール１３１
６のオペレーションを示す。モジュール１３１６は段階１６１０において、世代
ＩＤとステージエリア「ｓ」のルートディレクトリとを取得する。モジュール１
３１６は段階１６１５において、エディションｅの固有オブジェクトＩＤも取得
する。モジュール１３１６は段階１６２０において、新たなエディションを表し
且つネームフィールド、ルートディレクトリフィールド、世代ＩＤフィールド、
オブジェクトＩＤフィールド、ブランチフィールドを有するオブジェクトを作成
する。モジュール１３１６は段階１６３０において、新たなエディションの名前
をネームフィールドへ、ステージエリアの世代ＩＤを世代ＩＤフィールドへ、ス
テージエリア「ｓ」のルートディレクトリをルートディレクトリフィールドへ、
段階１６２５で得られたオブジェクトＩＤをオブジェクトＩＤフィールドへ、エ
ディションが存在するブランチＩＤをブランチフィールドへ入れる。

【００５５】 ステージエリアの世代ＩＤを取ることによって、モジュール１３１６は、ステ
ージエリア「ｓ」を新たなエディションへ本質的に変換する。結果的に、エディ
ションが生成された時に、エディション生成モジュール１３１６は段階１６４０
において、新たな世代ＩＤを取得し、段階１６５０において、この世代ＩＤをス
テージエリアへ割り当てる。

【００５６】 図１７ａ−ｃは、ブランチ生成モジュール１３４６のオペレーションを示す。
ブランチを生成するために、モジュール１３４６は段階１７０５において、現在
作成されつつあるブランチがメインブランチであるか否かを判定する。ブランチ
がメインブランチでない場合、モジュール１３４６は段階１７１０において、新
たなブランチが派生した、「エディションｂ」と呼ばれる、親ブランチからのベ
ースエディションの世代ＩＤを取得する。「エディションｂ」は親ブランチの上
に追加された任意のものである。次にモジュール１３４６は段階１７１５におい
て、「エディションｂ」の世代ＩＤから派生された新たな世代ＩＤを世代ＩＤモ
ジュール１３４８から取得する。次に「エディションｅ」と呼ばれる初期エディ
ションが、「エディションｂ」としての同じルートディレクトリと段階１７１５
で得られた世代ＩＤとを使って段階１７２０において生成される。更に、ゼロ又
はそれ以上のワークエリアが段階1７３０において作成され、各ワークエリアは エディションｅと同じルートディレクトリを有し、エディションｅの世代ＩＤか
ら派生されたのとは異なる世代ＩＤを有している。ワークエリアは、ブランチ作
成の時点又はそれよりも後の時点で作成される。エディションｅと同じルートデ
ィレクトリを有し且つエディションｅの世代ＩＤから派生された世代ＩＤを有す
るステージエリアが、段階1７４０において作成される。エディションｅ、ワー クエリア、ステージエリアは、図１４-１６で述べられた方法に従って作成され る。

【００５７】 段階１７０５を参照すると、作成中のブランチがメインブランチである場合、
モジュール１３４６は段階1７５０において、ｇ０と呼ばれるルート世代ＩＤを 取得する。ルート世代ＩＤは、固有の数を生成するための従来プログラムを使っ
て生成される数であり、別の世代ＩＤから派生されるものではない。次にモジュ
ール１３４６は段階１７５５において、ｄ０と呼ばれる空のディレクトリを生成
し、段階１７６０において、ｈ０と呼ばれるディレクトリのための履歴オブジェ
クトを生成する。モジュール１３４６は段階１７６５において、履歴オブジェク
トが世代ｇ０におけるディレクトリｄ０に関係することを示す履歴オブジェクト
へのエントリを追加する。このエントリは表記法（ｇ０，ｄ０）で表される。

【００５８】 モジュール１３４６は、履歴オブジェクトを作成した後、段階１７７０におい
て、ルートディレクトリｄ０とルート世代ｇ０とを有する初期エディションを生
成する。又、モジュール１３４６は段階１７７５において、１つ又はそれ以上の
ワークエリアと、１つのステージエリアを作成するが、それぞれのエリアは初期
エディション（即ち、空の）と同じルートディレクトリと、ルート世代から派生
されたのとは異なる世代ＩＤとを有している。ワークエリアはブランチ生成の時
に生成される必要はないこと、即ちそれより後に生成されてもよいことに注目さ
れたい。

【００５９】 追加アイテムモジュール１３１８により、ファイルやディレクトリのようなオ
ブジェクトをワークエリア又はステージエリアへ追加できる。図１８ａ−ｄは、
コンテンツ「ｐ」を有するアイテム「ｎ」をエリア「ａ」のディレクトリ「ｄ」
へ加えるための追加アイテムモジュール１３１８のオペレーションを示す。エリ
ア「ａ」はワークエリアでもステージエリアでもよく、アイテム「ｎ」はファイ
ルでもディレクトリでもよい。アイテム「ｆ」はファイルでもディレクトリでも
よい。アイテムを加えるため、モジュール１３１８は段階１８０５において、「
ｇ」と呼ばれるエリア「ａ」のための世代ＩＤを識別する。次にモジュール１３
１８は段階１８１０において、ディレクトリ「ｄ」を読み出し、段階１８１５に
おいて、世代「ｇ」用の世代ページがあるか否かを判定する。ディレクトリ「ｄ
」のための世代ページがない場合、モジュール１３１８は段階１８２０において
、世代ページを有し最も緊密な関係にある親世代（「最適一致世代」）の世代ペ
ージをコピーすることにより、ディレクトリ「ｄ」のための世代ページを生成す
る。世代ページを生成又は作成するための世代ページを見つけ出した後に、モジ
ュール１３１８は段階１８２５において、名前「ｎ」を有するアイテムに関する
世代ページのコンテンツをスキャンし、段階１８３５において、アイテム「ｎ」
が世代「ｇ」中のディレクトリ「ｄ」に存在するか否かを判定する。「ｎ」と名
付けられたアイテムが世代「ｇ」のディレクトリ「ｄ」に見つからない場合、モ
ジュール１３１８は段階１８４０において、コンテンツ「ｆ」が世代「ｇ」中の
アイテム「ｎ」に関係していることを示すエントリを備えた履歴オブジェクトを
履歴オブジェクト中に作成する。このようなエントリを表すために表記法（ｆ，
ｇ）を使う。続いて、モジュール１３１８は段階１８４５において、表記法（ｎ
，ｈ）で表されるエントリを、ファイル「ｎ」が履歴オブジェクト「ｈ」に関係
していることを示す世代ページ「ｇ」へ加える。アイテム「ｎ」をディレクトリ
「ｄ」へ加えるために、アイテム「ｎ」をディレクトリ「ｄ」へ仮想的にコピー
することも物理的にコピーすることもないことに注目されたい。ディレクトリ「
ｄ」は単なる参照アイテム「ｎ」である。

【００６０】 アイテム「ｎ」がディレクトリへ既に加えられている場合、段階１８３５での
質問への答はイエスとなるが、アイテム「ｎ」の更新されたバージョンが既存の
バージョン（即ち、新コンテンツがアイテム「ｎ」と現在関係付けられつつある
）に取って代わる。この場合、モジュール１３１８は段階１８５０において、フ
ァイル「ｎ」が変更された最も新しい世代のファイル「ｎ」に関係する履歴オブ
ジェクトのコンテンツをスキャンする。次にモジュール１３１８は段階１８５５
において、アイテム「ｎ」が世代「ｇ」で変更されたか否かを判定する（即ちモ
ジュール１３１８は、アイテム「ｎ」がエリア「ａ」において変更されたか否か
を判定する。何故ならエリア「ａ」は世代ＩＤ「ｇ」を有しているからである）
。アイテム「ｎ」が世代「ｇ」で変更されていない場合、次にモジュール１３１
８は段階１８６０において、コンテンツ「ｆ」が世代「ｇ」のファイルに関係し
ていることを示す履歴オブジェクトへエントリを追加する。アイテム「ｆ」は、
アイテム「ｎ」の以前のコンテンツを示すフィールドを有する（即ちアイテム「
ｆ」は、アイテム「ｎ」の以前のコンテンツへのポインタを含んでいる）。モジ
ュール１３１８は段階１８６５において、最も良好に一致する世代中の「ｎ」の
コンテンツを示すために、アイテム「ｆ」の以前のフィールドをセットする。

【００６１】 段階１８５５を参照すると、アイテム「ｎ」が世代「ｇ」で変更された場合、
モジュール１３１８は段階１８７０において、世代「ｇ」においてアイテム「ｎ
」のコンテンツがアイテム「ｆ」であることを反映するために、世代「ｇ」に関
係する履歴アイテムエントリを変更する。次にモジュール１３１８は段階１８７
５において、アイテム「ｆ」の以前のフィールドが世代「ｇ」の「ｎ」の以前の
コンテンツを指すように設定する。

【００６２】 リソースを再請求するために、オブジェクトが如何なるエリアからもアクセス
できない場合、当該オブジェクト（例：ディレクトリ、ファイル、履歴オブジェ
クト）は記憶装置から物理的に削除される。エリアへオブジェクトを加えたりエ
リアからオブジェクトを削除したりすることは、オブジェクトの物理的なコピー
が１つだけしばしば記憶されるので、仮想的に行える。従って、オブジェクトの
物理的なコピーを削除すべきか否かを判定するためには、何れかのエリアから当
該オブジェクトへアクセスできるか否かを知ることが必要である。あるエリアか
らオブジェクトへアクセスできる場合、そのオブジェクトは当該エリアにおいて
参照される。任意のエリアからあるオブジェクトへアクセスできるか否かを判定
するには、各オブジェクトのための参照カウントが維持され、参照カウントはオ
ブジェクトへアクセスすることのできるエリアの数を示すことになる。オブジェ
クトの参照カウントがゼロの場合、オブジェクトは削除することができる。

【００６３】 参照カウントを計算できるようにするため、各オブジェクトは「参照リスト」
と「反参照リスト」へ関係付けられる。参照リストは、オブジェクトが加えられ
たディレクトリを示し、参照される各ディレクトリにつき、当該オブジェクトが
ディレクトリに加えられた際の世代（即ちエリア）を示す。厳密には、１つのオ
ブジェクトがディレクトリに加えられる都度、１つのエントリが参照リストに加
えられ、当該オブジェクトがディレクトリに加えられた際の世代が示される。 反参照リストは、オブジェクトが取り除かれたディレクトリを示し、参照され
る各ディレクトリにつき、当該オブジェクトが取り除かれた際の世代を示す。厳
密には、１つのオブジェクトがディレクトリから取り出される都度、１つのエン
トリが反参照リストに加えられ、当該オブジェクトがディレクトリから取り除か
れた際のディレクトリと世代を示すことになる。

【００６４】 追加直接参照モジュール１３２２は、エントリを参照リストに加える。図１９
は、オブジェクト（例：ファイル又はディレクトリ又は履歴オブジェクト）がエ
リア「ａ」のあるディレクトリ「ｄ」に加えられる際の追加直接参照モジュール
１３２２のオペレーションを示す。オブジェクト「ｃ」がディレクトリ「ｄ」に
追加されるとき、「ｃ」に対するｄの直接参照が追加される。換言すると、「ｃ
」の参照リストは、「ｃ」がディレクトリ「ｄ」に加えられたことを示す。直接
参照を追加するために、追加直接参照モジュール１３２２はまず段階１９１０に
おいて、エリア「ａ」の世代を得るがこれを便宜上「ｇ」と呼ぶ。次に追加直接
参照モジュール１３２２は段階１９２０において、オブジェクト「ｃ」の参照リ
ストに、オブジェクト「ｃ」が世代「ｇ」でディレクトリ「ｄ」へ加えられたこ
とを示すエントリがあるか否かを判定する。便宜上このエントリを表記法（ｇ，
ｄ）で表す。（ｇ，ｄ）がオブジェクト「ｃ」の参照リストになければ、段階１
９３０において当該エントリが参照リストに加えられる。

【００６５】 （ｇ，ｄ）が参照リストに加えられた後、又は（ｇ，ｄ）が既に参照リストに
ある場合、追加直接参照モジュール１３２２は段階１９４０において、エントリ
（ｇ，ｄ）が反参照リストにあるか否かを判定する。オブジェクト「ｃ」が以前
に世代「ｇ」でディレクトリ「ｐ」から取り出されていたなら、エントリ（ｇ，
ｄ）は反参照リストにあることになる。エントリ（ｇ，ｄ）がオブジェクト「ｃ
」の反参照リストになければ、直接参照を加える処理は完了である。エントリ（
ｇ，ｄ）が反参照リストにあれば、当該エントリは段階１９５０において、反参
照リストから外される。更には、世代「ｇ」から直接派生した世代、それをｇ_i と呼ぶことにするがその各世代について、エントリ（ｇ_i，ｄ）が段階１９６０ において、反参照リストに加えられる。この最後の段階を行うのは、派生した世
代はその親世代と同じコンテンツから始まっているからである。従って、オブジ
ェクトが１つの世代でアクセスされ得るなら、子世代の派生後に当オブジェクト
が親ディレクトリに加えられていない限り、又はオブジェクトが子世代から特定
して取り出されてない限り、オブジェクトはその世代から派生した全子世代から
アクセスすることができる。必然的に、あるオブジェクトが既存の子世代を有す
るある世代においてあるディレクトリに追加される場合、オブジェクトは既存の
子世代が派生した時点では親世代の部分ではなかったので、反参照リストは、当
該オブジェクトが既存の子世代からアクセスされようがないことを示すはずであ
る。無論、オブジェクトは、図１８ａ−ｄに関連して図示され説明された方法を
使って、子世代に加えることもできる。

【００６６】 取り除き直接参照モジュール１３２４は、エントリを反参照リストに加える。
図２０は、オブジェクト「ｃ」がエリア「ａ」のディレクトリ「ｄ」から取り除
かれる場合の取り除き直接参照モジュール１３２４のオペレーションを示す。取
り除き直接参照モジュール１３２４は段階２０１０において、便宜上「ｇ」と呼
ぶ、エリアａの世代ＩＤを確認する。次に取り除き直接参照モジュール１３２４
は段階２０２０において、以前にオブジェクト「ｃ」が世代「ｇ」でディレクト
リ「ｄ」へ加えられたことを示すオブジェクトの参照リストにエントリがあるか
否かを判定する。このようなエントリを表記法（ｇ，ｄ）で表す。（ｇ，ｄ）が
参照リストになければ、オブジェクト「ｃ」は世代「ｇ」でのディレクトリ「ｄ
」に対する参照リストを有したことがなかったということで、処理は完了する。
従って、どの参照リストも取り除かれる必要はない。

【００６７】 （ｇ，ｄ）が参照リストにあれば、（ｇ，ｄ）は段階２０３０において、オブ
ジェクト「ｃ」の参照リストから取り除かれる。更に、世代「ｇ」から派生した
世代、それを「ｇ_i」と呼ぶことにするがその各世代につき、エントリ（ｇ_i，ｄ
）が反参照リストになければ、当該エントリは段階２０４０において、参照リス
トに加えられる。この段階を行うのは、オブジェクト「ｃ」が既存の子世代から
アクセス可能であったなら、オブジェクト「ｃ」が親世代から取り除かれている
という事実に関わらず、オブジェクト「ｃ」へは既存の子世代からアクセスでき
るということを参照リストが示すからである。

【００６８】 段階２０４０の後、取り除き直接参照モジュール１３２４は段階２０５０にお
いて、エントリ（ｇ、ｄ）が反参照リストにあるか否かを判定する。当該エント
リがまだ反参照リストになければ、当該エントリが段階２０６０において、反参
照リストに加えられる。そうでなければ、直接参照を取り除く処理は完了する。
エントリ（ｇ，ｄ）が反参照リストに既にあるはずがないとしても、エントリが
より早い時期に反参照リストへ間違って加えられた場合に備えて、取り除き直接
参照モジュール１３２４は、この判定を行う。 参照カウントモジュール１３２０は、あるアイテムに対する参照の数を計算す
る。計算のため、参照カウントモジュール１３２０は、２個組のリストを維持す
るが、これは初期には空である。参照カウントモジュール１３２０は、アイテム
「ｆ」に対して行われた参照の数を表すために、整数ｎも使用するが、これは最
初ゼロである。

【００６９】 図２１ａ−ｂは、あるアイテム「ｆ」の参照カウントを計算するための参照カ
ウントモジュール１３２０のオペレーションを示す。参照カウントモジュール１
３２０は段階２１１０及び段階２１２０において、アイテム「ｆ」の参照リスト
及び反参照リストを検索する。参照カウントモジュールは段階２５２５で、便宜
上「ｇ」と呼ぶ、系図ツリー（本発明の全エリアは系図に編成できるということ
を思い出されたい）のルートノードの世代ＩＤを得る。参照カウントモジュール
１３２０は段階２１３０において、世代「ｇ」を有する参照リスト中の全エント
リを見つける。例えば、アイテム「ｆ」が世代「ｇ」においてディレクトリｄ₁ へ加えられた場合、参照リストにはエントリ（ｇ，ｄ₁）があるはずで、参照カ ウントモジュール１３２０はこのエントリを突き止めるであろう。世代「ｇ」を
持つエントリについて、参照カウントモジュール１３２０は段階２１３０におい
て、エントリ（アイテム名，＋）をリスト「ｐ」に加えるが、この場合の「アイ
テム名」は世代「ｇ」において参照されたアイテムの名前である。「＋」はアイ
テムが（反参照リストとは反対の）参照リスト中に参照されたことを意味する。
例えば、エントリ（ｇ，ｄ１）がアイテム「ｆ」の参照リスト中に発見されたな
ら、エントリ（ｄ１，＋）がリスト「ｐ」に加えられる。リスト「ｐ」が同じア
イテム名を持つエントリ（例：ｄ１，−）を既に含んでいる場合、参照カウント
モジュールはそのエントリが（アイテム名，＋）へ設定されるのを保証する。

【００７０】 参照カウントモジュール１３２０は段階２１４０において、世代「ｇ」を備え
た反参照リスト中の全エントリを見つけるために、反参照リストの探索もする。
世代「ｇ」の反参照リスト中の各エントリにつき、参照カウントモジュール１３
２０は段階２１４０において、エントリ（アイテム名，−）をリスト「ｐ」へ加
えるが、この場合の「−」はアイテムが反参照リスト中で参照されたことを意味
する。リスト「ｐ」が同じアイテム名を持つエントリを既に含んでいる場合、参
照カウントモジュールはそのエントリが（アイテム名，−）へ設定されるのを保
証する。

【００７１】 次に参照カウントモジュール１３２０は段階２０５０において、「＋」を持つ
リスト「ｐ」中の各エントリにつき、ｎ＝ｎ＋１を設定する。ｎは初期にはゼロ
に設定されていることを思い出していただきたい。次に参照カウントモジュール
１３２０は段階２１６０において、世代「ｇ」が子世代（即ち、世代「ｇ」から
派生した世代）を有しているか否かを判定する。そうでない場合には、参照カウ
ントは段階２１７０において完了し、ｎはアイテム「ｆ」への参照の数となる。
世代「ｇ」が子世代を有する場合、各子世代につき、参照カウントモジュール１
３２０は段階２１８０において、「ｇ」を子世代の世代ＩＤに等しく設定し、段
階２１３０へ戻る。

【００７２】 図２２は、エリア「ａ」のディレクトリ「ｄ」のコンテンツを読み出すための
読み出しディレクトリモジュール１３２６のオペレーションを示す。読み出しデ
ィレクトリモジュール１３２６は段階２２１０において、エリアａの世代を得る
が、これを「ｇ」と称する。読み出しディレクトリモジュール１３２６は、ディ
レクトリ全体を構文解析し、世代「ｇ」のための世代ページがあるか否かを段階
２２２０において判定する。ディレクトリ「ｄ」が既にエリアａで変更されてい
たなら、世代「ｇ」のための世代ページがあることになる。世代「ｇ」のための
世代ページがあるなら、読み出しディレクトリモジュール１３２６は段階２２３
０において、世代ページ「ｇ」上のエントリのリストを返却する。そうでないな
らば、ディレクトリは段階２２４０において、最も関係の深い親世代ページの世
代ページ（最適一致世代ページ）上のエントリのリストを返却する。

【００７３】 読み出しディレクトリモジュールのオペレーションの例を図１２に示した例を
使って説明する。世代Ｇ３を有するエリア中のディレクトリのコンテンツを読み
出すに当たり、読み出しディレクトリモジュール１３２６は、世代ページＧ３上
の（複数）エントリのリストを戻すが、本例ではこれはエントリ（ｍ、ｈ０）で
ある。

【００７４】 図面１２の世代が図１０に示す方法で関連付けられていると仮定する。世代Ｇ
４中のディレクトリ「ｄ」のコンテンツを読み出すために、読み出しディレクト
リモジュール１３２６は、Ｇ４用の世代ページがあるか否かを判定する。Ｇ４用
の世代ページがないことから、読み出しディレクトリモジュール１３２６は最適
一致世代ページにつき探索する。Ｇ１はＧ４に最も近密な親世代であるが、Ｇ１
に当たる世代ページはない。Ｇ０が次に近密な親世代であり、Ｇ０に当たる世代
ページはあるので、Ｇ０世代ページ中のエントリのリストが、Ｇ４のディレクト
リのコンテンツとして返却される。

【００７５】 図２３ａ−ｂは、世代ＩＤ「ｇ」を有するエリア「ａ」中のディレクトリ「ｄ
」からアイテム「ｎ」が取り除かれる場合の、取り除きアイテムモジュール１３
２８のオペレーションを示す。アイテムｎは、ファイル又は別のディレクトリの
ようなディレクトリ中の何れのオブジェクトでもよい。アイテムをディレクトリ
「ｄ」から取り除くために、ディレクトリ「ｄ」は段階２３１０において、図２
２に関連して説明した方法に従って読み出される。取り除きアイテムモジュール
１３２８は段階２３２０において、世代「ｇ」用の世代ページがディレクトリ「
ｄ」にあるか否かを判定する。ない場合には、最も近密な親世代（最適一致世代
）から世代ページをコピーすることにより、段階２３３０おいて世代「ｇ」用の
世代ページが作成される。

【００７６】 取り除きアイテムモジュール１３２８は段階２３３０において、世代ページ「
ｇ」中にアイテムｎに当たるエントリがあるか否かを判定する。ない場合、取り
除きアイテムモジュール１３２８は段階２３３０において、アイテムｎが世代「
ｇ」のディレクトリ「ｄ」にないので従って世代「ｇ」でディレクトリから取り
除くことが不可能であるという理由で、エラーが起きたことを示す。

【００７７】 段階２３３０に戻ると、世代ページｇにアイテムｎに当たるエントリがあるな
ら、取り除きアイテムモジュール１３２８は段階２３５０において、ｎに対応す
る履歴オブジェクトを取得する。取り除きアイテムモジュール１３２８は段階２
３５５において、アイテムｎが世代「ｇ」中に変更されたことを履歴オブジェク
トが示しているか否かを判定する。換言すると、取り除きアイテムモジュール１
３２８は、履歴オブジェクトが、世代が「ｇ」のエントリを含んでいるか否かを
判定する。

【００７８】 アイテムｎが世代「ｇ」で変わっていなければ、取り除きアイテムモジュール
１３２８は段階２３７０において、アイテムｎが世代「ｇ」でディレクトリ「ｄ
」から取り除かれたことを示すエントリを履歴オブジェクトへ加える。アイテム
ｎは本処理では仮想的に削除されるので、このエントリを追加することにより、
アイテムｎをディレクトリ「ｄ」から世代「ｇ」で有効に削除することになる。
このエントリは表記法（ｇ，ｚ）により表され、この場合「ｚ」はアイテムが取
り除かれてしまったことを示すオブジェクトを表す。ｚオブジェクトがアイテム
ｎのために作成されてなかったならば、取り除きアイテムモジュール１３２８は
ｚオブジェクトを作成する。

【００７９】 段階２３５５に関して、アイテムｎが世代「ｇ」で変更されていたなら、取り
除きアイテムモジュール１３２８は段階２３６０において、ｎがディレクトリ「
ｄ」から世代「ｇ」で取り除かれたことを示すために、世代「ｇ」に対応する履
歴オブジェクト中のエントリを変更する（即ち、エントリは（ｇ，ｚ）となる）
。取り除きアイテムモジュール１３２８は、まだオブジェクトが存在していなけ
れば、アイテムｎのための「ｚ」を作成する。

【００８０】 図１２に示されたファイルコンテンツ１２３５のように、ｚオブジェクトはあ
るアイテムの以前のコンテンツを示すフィールドも有している。このフィールド
は「以前のフィールド」と称される。段階２３６０又は段階２３７０の後で、ｚ
オブジェクトの以前のフィールドは段階２３８０において、以前のコンテンツｎ
を指すように世代「ｇ」において設定される。

【００８１】 図２４ａ−ｂは、世代ＩＤ「ｇ」を有するワークエリア「ａ」のディレクトリ
「ｄ」中にファイル「ｎ」を編集するための編集ファイルモジュール１３２０の
オペレーションを示す。編集ファイルモジュール１３２０は段階２４０５におい
て、ファイル「ｎ」に対する書き込みコマンドを受信する。編集ファイルモジュ
ール１３２０は段階２４１０において、次にファイルｎについての履歴オブジェ
クトを取得し、ファイルｎが世代「ｇ」で変更されたか否か（即ち、世代が「ｇ
」のエントリがあるか否か）を段階２４２０において判定する。そうであるなら
、編集ファイルモジュール１３２０は段階２４３０において、世代「ｇ」でファ
イルｎに関係付けられたコンテンツへファイル「ｎ」に対する変更を全て書き込
む。

【００８２】 履歴オブジェクトが世代「ｇ」のエントリを持たない場合、編集ファイルモジ
ュール１３２０は段階２４４０において、最適一致世代を有するエントリを見つ
ける。編集ファイルモジュール１３２０は次に段階２４５０において、ｆ１と呼
ばれる、段階２４４０でエントリに関係付けられたファイルをコピーし、ファイ
ルｆ１の新コピーに全変更を段階２４６０において書き込むが、この書き込まれ
たファイルをｆ２と呼ぶ。世代「ｇ」においてファイルｎのコンテンツがファイ
ルｆ２のコンテンツであることを示すエントリが段階２４７０において、履歴オ
ブジェクトに加えられる。換言すれば、編集ファイルモジュール１３２０は表記
法（ｇ、ｆ２）により表されるエントリを履歴オブジェクトへ加えるのである。

【００８３】 図２５は、ファイル又はディレクトリである、エリアａのディレクトリｄ１中
のアイテムｎ１を、エリアａのディレクトリｄ２中のアイテムｎ２に再命名する
ための再命名モジュール１３３２のオペレーションを示す。再命名モジュール１
３３２は段階２５１０において、ディレクトリｄ１のアイテムｎ１の履歴オブジ
ェクトを取得するが、この履歴オブジェクトはｈ１と呼ばれる。このような履歴
オブジェクトが存在しない場合は、再命名モジュール１３３２はユーザにエラー
が発生したと報告する点に留意されたい。履歴オブジェクトを取得後、再命名オ
ブジェクト１３３２は段階２５２０において、名前ｎ２を有するアイテムがディ
レクトリｄ２に存在するか否か判定する。存在するならば、再命名モジュールは
段階２５２３において、アイテムｎ２に対する上書き防止があるか否かを判定す
る。１実施例では、ディレクトリに対する上書き防止はあるがファイルに対して
はない。上書き防止が存在する場合、再命名モジュール１３３２は段階２５２７
において、アイテムｎ２がディレクトリｄ２に既に存在することを報告する。上
書き防止がない場合、再命名モジュール１３３２は段階２８３０において、既存
のアイテムｎ２を図２３ａ−ｄに関連して図示及び説明した方法に則りディレク
トリｄ２から取り除く。

【００８４】 既存のアイテムｎ２がディレクトリｄ２から一旦取り除かれてしまった場合、
又はアイテムｎ２がディレクトリｄ２には存在しなかった場合、再命名モジュー
ル１３３２は段階２５４０において、名前ｎ２を持つ新アイテムをディレクトリ
ｄ２に加える。再命名モジュール１３３２は、履歴オブジェクトｈ１をディレク
トリｄ２のアイテムｎ２に関係付ける。アイテムｎ２のコンテンツの「以前のフ
ィールド」において、再命名モジュール１３３２は、ｎ１がｎ２という「先祖か
らの再命名」（以下に定義する）であることを示す。再命名処理は、ｄ１＝ｄ２
なら同じであることに留意されたい。

【００８５】 図２６ａ−ｂは、エリアａのディレクトリ「ｄ」につきフルネーム経路を生成
するための生成ディレクトリ経路モジュール１３３４のオペレーションを示す。
生成ディレクトリ経路モジュール１３３４は、エリアａのディレクトリ「ｄ」を
読み出し、ディレクトリ「ｄ」に対する親ディレクトリを識別するが、これをＰ _d と呼ぶ。本発明の１実施例によれば、親ディレクトリはディレクトリ中のエン トリ「．．」と関係付けられる。本実施例では、生成ディレクトリ経路モジュー
ル１３３４はエントリ「．．」に対応するディレクトリを識別する。

【００８６】 モジュール１３３４はエリアａ中のディレクトリＰ_dを読み出し、ディレクト リ「ｄ」に対するエントリを見つける。モジュール１３３４は次にディレクトリ
経路中の名前としてディレクトリ「ｄ」を識別する。

【００８７】 このアルゴリズムは、ルートディレクトリに達するまで繰り返される。厳密に
は、ディレクトリ「ｄ」に関連して上述した方法が、ディレクトリＰ_dにつき、 そして次にディレクトリＰ_dの親ディレクトリにつきというように、ルートディ レクトリに到るまで以下同様に繰り返される。発見される名前はディレクトリ経
路中の名前である。名前は、ディレクトリ経路名中に末尾から先頭への順序で見
つけられる。

【００８８】 図２７は、エリア「ａ」のディレクトリ「ｄ」中の履歴オブジェクト「ｈ」の
ベースネームを生成するためのベースネーム生成モジュール１３３５のオペレー
ションを示す。ベースネーム生成モジュール１３３５は段階２７１０において、
ディレクトリ「ｄ」のエリアａに対応する世代ページを読み出す。ベースネーム
生成モジュール１３３５は段階２７２０において、履歴オブジェクト「ｈ」を持
つエントリを識別する。エントリ中の履歴オブジェクト「ｈ」に対応するアイテ
ムの名前が、捜し求められたベースネームである。例えば、エントリ（ｎ，ｈ）
がエリアａのディレクトリ「ｄ」に発見されたなら、「ｎ」が履歴オブジェクト
のベースネームということになる。

【００８９】 図２８ａ−ｃは、履歴オブジェクト「ｈ」とコンテンツ「ｆ」を有するアイテ
ム「ｎ」を、世代ＩＤｇを有するステージエリアのディレクトリ「ｄ」へ提出す
るための提出モジュール１３３６のオペレーションを示す。提出オペレーション
は、ワークエリアのコンテンツをステージエリアに提出するために使われる。フ
ァイルのコンテンツはその履歴オブジェクトにより定義されるので、ファイルの
履歴オブジェクトはステージエリアに実際に提出されるものである。提出モジュ
ール１３３６は段階２８０５において、図２６及び図２７に関連して図示及び説
明した方法に則り、ディレクトリ「ｄ」の完全経路名とエリアａのベースネーム
履歴オブジェクト「ｈ」を計算することにより、履歴オブジェクト「ｈ」の完全
経路を取得する。提出モジュール１３３６は段階２８１０において、同じ完全経
路名を持った対応するアイテムがステージエリアにあるか否かを判定する。これ
は、ステージエリアの別のオブジェクトが履歴オブジェクト「ｈ」と同じ完全経
路名を有するか否かを判定するために、ディレクトリ「ｄ」を（ディレクトリ読
み出しモジュール１３２６で）繰返し読み出すことにより行なわれる。

【００９０】 対応するアイテムがステージエリアにない場合、提出モジュール１３３６は段
階２８３０において、段階２８０５で計算されたディレクトリ経路がステージエ
リアに存在するか否かを確かめる。存在しなかった場合、ディレクトリ経路が段
階２８３５において作成され、ファイル「ｆ」は段階２８４０において、凍結し
た印を付けられる。段階２８３０又は段階２８４０の後、提出モジュール１３３
６は段階２８４５において、追加アイテムモジュール１３１８を呼び出し、コン
テンツ「ｆ」を持つアイテムｎをステージエリアａのディレクトリ「ｄ」へ加え
る。提出モジュール１３３６は段階２８４０において、エントリ（ｇ，ｆ）を履
歴オブジェクトへ追加する。

【００９１】 次に提出モジュール１３３６は、アイテム「ｆ」がディレクトリであるか否か
を判定する。ディレクトリでなければ提出処理は完了する。アイテム「ｆ」がデ
ィレクトリであるなら、各子ディレクトリｄ_iにつき、提出モジュール１３３６ はエントリ（ｇ，ｄ_i）をワークエリアのｄ_iに対応付けられた履歴オブジェクト
へ加える。この段階により、ディレクトリがステージエリアに提出される時に、
その子ディレクトリも確実に提出されることになる。

【００９２】 段階２８１０に戻ると、ステージエリアに対応するアイテムがあるなら、提出
モジュール１３３６は段階２８１５において、矛盾照合モジュール１３３８（以
下に説明）を呼び出し、「ｈ_s」と呼ぶ対応する履歴オブジェクトと履歴オブジ ェクト「ｈ」の間に矛盾があるか否か判定する。履歴オブジェクト「ｈ」と「ｈ _s 」は、ａ）「ｈ」と「ｈ_s」が同じ、又はｂ）「ｈ」が「ｈ_s」から派生、或い はｃ）「ｈ_s」が「ｈ」から派生、の場合には矛盾していない。「ｈ」及び対応 する履歴オブジェクト「ｈ_s」の間に矛盾がなければ、提出モジュール１３３６ は段階２８４０に進む。そうでなければ、提出モジュール１３３６は段階２８２
０において、既存ファイルが上書きされるようにする上書きモードが有効か否か
を判定する。有効ならば、提出モジュール１３３６は段階２８４０に進む。そう
でなければ、矛盾があるために提出は無効になる。

【００９３】 図２９は、ブランチ「ｂ」のエリアａ_targetの矛盾につき、ファイルｆ_target をファイルｆ_referenceに対して照合する場合の、矛盾照合モジュール１３３８ のオペレーションを示す。矛盾照合モジュール１３３８は段階２９１０において
、ｆ_targetがブランチ「ｂ」にロックされているか否かを判定する。ブランチ上
のたった１個のワークエリアしかファイルをステージエリアに提出できない場合
は、そのファイルはブランチにロックされる。ファイルをロックすることは、矛
盾を避ける手段を提供することになる。ｆ_targetがブランチ「ｂ」にロックされ
るなら、矛盾照合モジュール１３３８は段階２９２０において、ｆ_targetについ
てのロックがａ_targetとは違うエリアにより所有されているか否かを判定する。
所有されている場合は、矛盾が存在し、ｆ_targetはエリアａ_targetに提出される
ことはありえない。

【００９４】 ｆ_targetがブランチ「ｂ」にロックされていない場合、若しくはｆ_targetのロ
ックがａ_targetに所有されている場合には、矛盾照合モジュールは段階２９３０
において、ｆ_targetとｆ_referenceが同じコンテンツを指しているか（即ち、ｆ_{t arget} とｆ_referenceが同じか）否かを確かめる。それらが同じコンテンツを指し
ている場合は、矛盾照合モジュール１３３８は矛盾がないことを発見する。２個
のファイルが同じコンテンツを有してない場合は、矛盾照合モジュール１３３８
は段階２９４０において、ｆ_referenceがｆ_targetの先祖（即ち、以下に定義す るように、同一名の先祖、先祖からのコピー、又は先祖からの再命名）であるか
否かを判定する。ｆ_referenceが先祖であるなら、ｆ_targetはｆ_referenceの望ま
しい修正である可能性が高いので、矛盾はない。そうでないなら、矛盾が存在す
る。

【００９５】 図３０ａ−ｂは、エリアａ_targetのディレクトリｄ_targetを、エリアａ_{refere nce} のディレクトリｄ_referenceと比較するための比較ディレクトリモジュール１
３４０のオペレーションを示す。比較するために、比較ディレクトリモジュール
１３４０は段階３００５において、図２２に関連して図示及び説明した方法に則
り、エリアａ_targetのディレクトリｄ_targetのコンテンツを読み出す。矛盾照合
モジュールも段階３０１０において、図２２に関連して図示及び説明された方法
に則り、エリアａ_referenceのディレクトリｄ_referenceのコンテンツを読み出す
。

【００９６】 比較ディレクトリモジュール１３４０は段階３０１５において、ディレクトリ
ｄ_targetの最初のアイテムを識別し、ディレクトリｄ_targetの最初のアイテムと
同じ名前のアイテムがディレクトリｄ_reference中にあるか否かを段階３０２０ において判定する。ない場合には、比較ディレクトリモジュール１３４０は、ｄ _target 中に識別されるアイテムに一致するアイテムがｄ_referenceにはないこと を段階３０４５において報告し、段階３０５０に進む。そうでない場合には、比
較ディレクトリモジュール１３４０は段階３０２５において、同一名を有する２
個のアイテムが同じコンテンツを有するか否かを判定する。このような比較は、
各アイテムの履歴オブジェクトを参照することにより行なわれ、エリアａ_{refere nce} のディレクトリｄ_referenceの履歴オブジェクトが、エリアａ_targetのディレ
クトリｄ_targetの履歴オブジェクトと同じコンテンツを指しているなら、双方の
ディレクトリのコンテンツは同じである。コンテンツが同じであるなら、比較デ
ィレクトリモジュール１３４０は段階３０３０において、アイテムが同じ名前と
コンテンツを有することを報告し、比較ディレクトリモジュール１３４０は段階
３０５０に進む。双方のコンテンツが同じでないなら、比較ディレクトリモジュ
ール１３４０は段階３０３５において、名前は同じであるがコンテンツは違うこ
とを報告し、比較ディレクトリモジュール１３４０は段階３０５０へ進む。

【００９７】 段階３０５０では、比較ディレクトリモジュール１３４０は段階３０５０にお
いて、ｄ_target中に別のアイテムがあるか否かを確かめる。ｄ_target中に別のア
イテムがあれば、比較ディレクトリモジュール１３４０は段階３０５３において
、次のアイテムを識別し、段階３０２０へ戻る。ｄ_target中に別のアイテムがな
ければ、比較ディレクトリモジュール１３４０は段階３０５５において、ｄ_{refe rence} 中の最初のアイテムを識別する。比較ディレクトリモジュール１３４０は 段階３０６０において、識別されたアイテムがｄ_targetのアイテムと同じ名前を
有するか否かを判定する。同じ名前を有していない場合は、比較ディレクトリモ
ジュール１３４０は段階３０６５において、ｄ_target中に識別されたアイテムが
ｄ_reference中の何れのアイテムにも一致しないことを報告し、段階３０６７に 進む。識別されたアイテムがｄ_target中のアイテムと同じ名前を有するなら、識
別されたアイテムは段階３０２０で既に発見されていることになり、従って比較
ディレクトリモジュール１３４０は段階３０６７に進む。

【００９８】 段階３０６７では、比較ディレクトリモジュール１３４０は、ディレクトリｄ _reference に別のアイテムがあるか否かを判定する。ｄ_referenceにこれ以上他の
アイテムがないことに応じて、ｄ_targetとｄ_referenceの比較に関する処理は完 了する。そうでないなら、比較モジュール１３４０は段階３０７０において、ｄ _reference の次のアイテムを取得し、段階３０６０に戻る。

【００９９】 比較ファイルモジュール１３４１は、（ディレクトリを比較する比較ディレク
トリモジュール１３４０とは反対に）ファイルを比較する。ファイルは、それら
がステージエリアに提出される際に比較される。更には、ウェブサイト開発者は
ファイルをそれぞれ個別のワークエリアで比較することを望むかもしれない。

【０１００】 ファイルの比較には、ファイルの先祖を調べることも含まれる。ファイルが有
する可能性のある先祖の３つの型は、同一名先祖、先祖からのコピー、及び先祖
からの再命名である。

【０１０１】 同一名先祖は、「ｆ」と呼ぶ、あるファイルの前のバージョンであって、ファ
イル「ｆ」と同じ名前（即ち「ｆ」）を有するが、その場合同一名先祖はファイ
ル「ｆ」と同じエリアへ以前に提出されている。ファイルの「以前のフィールド
」（例：図１２のフィールド１２４０）は当該ファイルの同一名先祖を指す。

【０１０２】 ファイルの先祖からのコピーは、「ｆ」と呼ばれるが、そのコンテンツがコピ
ーされてファイル「ｆ」になったファイルである。ファイルに関してのコピー作
成オペレーション又は先祖戻りオペレーションは、先祖からのコピーでワークエ
リアにファイルを作り出すことになる。オペレーションにより既存ファイルに上
書きが行われるならこれが起きる。例えば、ファイルｅ２をステージエリアにあ
るファイルとしよう。ファイルｕは、ワークエリアにあってファイルｅ２と矛盾
しているものとする。ファイルｕのコンテンツをファイルｅ２のコンテンツのコ
ピーに置き換えることによりファイルｕが更新される場合、古いファイルｕは更
新されたファイルｕの同一名先祖であり、ファイルｅ２は更新されたファイルｕ
の先祖からのコピーである。ファイルｅ２は、別のエリア又は別のブランチから
のファイルであることもある。ファイルｅ２は、ファイルｕのバージョン履歴中
のファイル、又は別のブランチ上の別のファイルのバージョン履歴中のファイル
であることがあり得る。あるファイルが先祖からのコピーを有するなら、当該フ
ァイルの「以前のフィールド」（例：図１２のフィールド１２４０）は、同一名
先祖を指すと同時に先祖からのコピーも指す。

【０１０３】 先祖からの再命名というファイル、これを「ｆ」と呼ぶが、このファイルはそ
れよりファイル「ｆ」が再命名される命名元のファイルである。ファイルが先祖
からの再命名を有する場合は、当該ファイルの「以前のフィールド」は同一名先
祖を指すと同時に先祖からの再命名も指す。

【０１０４】 図３１ａ−ｂは、ディレクトリｄ_targetのファイルＦ_targetをディレクトリｄ _reference のファイルＦ_referenceと比較する場合の比較ファイルモジュール１３
４１のオペレーションを示す。比較ファイルモジュール１３４１は段階３１１０
において、ディレクトリｄ_targetのファイルＦ_targetのコンテンツを保有してい
る、ｆ_tと呼ばれるファイルをルックアップする。Ｆ_targetとｆ_tとの違いは、Ｆ _target がディレクトリ中のファイルの名前であるのに対し、ｆ_tはディレクトリ ｄ_targetのファイルＦ_targetの実際のコンテンツであるという点に留意されたい
。Ｆ_targetとｆ_tとの違いは、図１２に示すディレクトリ中の「ｍ」と名付けら れたファイルと世代Ｇ０のファイル「ｍ」のコンテンツ「Ａ」との違いに似てい
る。

【０１０５】 比較ファイルモジュール１３４１は段階３１２０において、ｆ_rと呼ばれる、 ディレクトリｄ_referenceのファイルＦ_referenceのコンテンツを保有するファイ
ルをルックアップする。比較モジュールは次に段階３１３０において、ｆ_rとｆ_t が同一であるか否かを判定する。同一であるなら、比較ファイルモジュール１３
４１は段階３１４０において、Ｆ_referenceとＦ_targetが同一であると報告する 。

【０１０６】 ｆ_rとｆ_tが同一でないなら、比較ファイルモジュール１３４１は段階３１４５
において、Ｆ_referenceがＦ_targetの先祖であるか否かを判定する。各ファイル のコンテンツは、ファイル（例：以前のコンテンツ）の同一名先祖を指す（「以
前のフィールド」の）ポインタを含んでいること、及び、当該ファイルが先祖か
らのコピー又は先祖からの再命名を有する場合、各ファイルのコンテンツはこの
ような先祖を指すポインタを含んでいることに留意されたい。比較モジュールは
ｆ_t並びにその先祖の「以前のフィールド」をずっと横断して戻りながらｆ_rを探
索する。ｆ_rが横断された「以前のフィールド」の１つに現れると、Ｆ_reference はＦ_targetの先祖ということであり、比較ファイルモジュール１３４１は段階３
０５０において、Ｆ_targetがＦ_referenceの変更型であることを報告する。

【０１０７】 Ｆ_referenceがＦ_targetの先祖でない場合は、比較ファイルモジュール１３４ １は段階３１５５において、Ｆ_targetがＦ_referenceの先祖であるか否かを判定 する。厳密には、比較モジュールはｆ_r並びにその先祖の「以前のフィールド」 をずっと横断して戻りながらｆ_tを探索する。ｆ_tが横断された「以前のフィール
ド」の１つに現れると、比較ファイルモジュール１３４１は段階３１６０におい
て、Ｆ_targetがＦ_referenceの変更型あることを報告する。そうでなければ、比 較ファイルモジュール１３４１は段階３１６５において、Ｆ_targetとＦ_{referenc e} の両方の先祖であるファイルがあるか否かを判定する。共通ファイルがある場 合には、比較ファイルモジュール１３４１は段階３１７０において、Ｆ_{referenc e} とＦ_targetが共通の先祖を有すると報告し、共通ファイルが存在しない場合に は、モジュールは、Ｆ_targetはＦ_referenceと無関係である旨を報告する。

【０１０８】 エリア削除モジュール１３４２は、ユーザ又はシステム管理者がもはや必要と
しないエリアを削除する。図３２は、エリア「ａ」を削除する場合のエリア削除
モジュール１３４２のオペレーションを示す。エリア削除モジュールは段階３２
１０において、エリアａのディレクトリツリーを検索して、子供を持たないノー
ド（例：ディレクトリ）を段階３２３０において見つけるが、便宜上このノード
を「ｃノード」と呼ぶ。エリア削除モジュール１３４２は、ｃノードをその（複
数）親ディレクトリから取り除くために、取り除きアイテムモジュール１３２８
を呼び出す。エリア削除モジュール１３４２は又、親ディレクトリに対する参照
をｃノードの参照リストから段階３２４０において取り除くために、取り除き直
接参照モジュール１３２４も呼び出す。次にエリア削除モジュール１３４２は参
照カウントモジュール１３２０を呼び出し、参照カウントがゼロであるか否かを
段階３２６０において判定し、それがゼロである場合、ｃノードに対応付けられ
た物理オブジェクトが記憶装置から段階３２７０において削除される。そうでな
い場合には、ｃノードがエリアａからは取り除かれていても、依然として他のエ
リアに存在することから、ｃノードに関係付けられた物理オブジェクトは記憶装
置から削除されない。参照カウントを判定後、エリア削除モジュール１３４２は
段階３２８０において、当該エリアにノードが残っているか否かを判定する。残
っている場合にはモジュール１３４２は段階３２３０に戻る。そうでなければ、
エリア削除処理は完了する。

【０１０９】 図３３ａ−ｂと図３４はロックモジュール１３４６のオペレーションを示す。
図３３ａ−ｂは、ブランチ「ｂ」に沿ってエリアａのディレクトリ「ｄ」中のア
イテム「ｆ」にロックを作成するためのロックモジュール１３４６のオペレーシ
ョンを示す。このようなロックを創造するために、ロックモジュール１３４６は
段階３３１０において、エリアａのディレクトリ「ｄ」中のアイテム「ｆ」の完
全経路名を確定し、次に段階３３２０において、他のロックが同一の完全経路名
を持っているか否かを確かめる。持っているなら、ロックモジュール１３４６は
段階３２５０において、矛盾しているロックのせいでロック作成オペレーション
が無効となった旨を報告する。他の如何なるロックも同一完全経路名を有してい
なければ、ロックモジュール１３４６は段階３２３０において、段階３３１０で
識別された完全経路名を含むロックを作成し、段階３２４０において、そのロッ
クにロックの所有者としてのエリアａの印を付ける。

【０１１０】 図３４は、エリアａのディレクトリ「ｄ」中のアイテムがロックされているか
否かを判定するためのロックモジュール１３４６のオペレーションを示す。ロッ
クモジュール１３４６は段階３４１０において、エリアａのディレクトリ「ｄ」
中のアイテム「ｆ」の完全経路名を確認し、次に同一完全経路名を有するロック
がブランチ「ｂ」にあるか否かを段階３４２０において判定する。なければ、ロ
ックモジュールは段階３４３０において、アイテム「ｆ」がロックされていない
旨を報告する。そうでなければ、ロックモジュールは段階３４４０において、ア
イテム「ｆ」がロックされていると報告する。

【０１１１】 ウェブサイト開発ソフトウェアについて述べたが、これよりＨＴＴＰプロトコ
ルバーチャライゼーションモジュール１３７（「バーチャライゼーションモジュ
ール１３７」）について１つの実施例により説明する。

【０１１２】 各エリアは、ＨＴＴＰプロトコルレベルでは完全なウェブサイトと見える。各
エリア用に別個のウェブサーバを持つことなくこれを実現するために、バーチャ
ライゼーションモジュール１３７は単一ウェブサーバを複数のウェブサーバに見
えるようにすることができる。これにより、開発費用及び保守費用を大幅に削減
できると同時に、各エリアはＨＴＴＰプロトコルレベルで完全なウェブサイトに
なることができる。

【０１１３】 図３５は、開発ワークステーション上のウェブブラウザ１１０と、バーチャラ
イゼーションモジュール１３７と、ウェブサーバ１４５の間の通信経路を示す。
開発ワークステーション上のウェブブラウザ１１０は、ウェブサイトコンテンツ
用の（以下に述べるようにリンクの型により異なるが）全て又は選択されたＨＴ
ＴＰリクエストをバーチャライゼーションモジュール１３７へ経路付けするため
に方向決めされる。必要な場合には、バーチャライゼーションモジュール１３７
は、リクエストのディレクトリ経路を変更するので、ディレクトリ経路はリクエ
ストが生じた元のエリア（このエリアを「ビューイング域」と呼ぶ）又は別の希
望場所（以下に説明）に対応するようになる。換言すると、バーチャライゼーシ
ョンモジュール１３７へ送信されたＨＴＴＰリクエストは、必要ならば、ビュー
イングエリア又は他の希望場所に対応するファイルシステムに方向を再方向付け
されるということである。

【０１１４】 ＨＴＴＰリクエストを処理した後、バーチャライゼーションモジュール１３７
はＨＴＴＰリクエストをウェブサーバ１４５に転送すると、ウェブサーバ１４５
は当該リクエストにより規定された場所から要求された文書を検索する。ウェブ
サーバ１４５が要求された文書（又はそれが発見されない場合はエラー信号）を
バーチャライゼーションモジュール１３７に送り返すと、モジュール１３７はこ
の要求された文書（又はエラー信号）をウェブブラウザに転送して戻す。

【０１１５】 バーチャライゼーションモジュール１３７は、ＨＴＴＰリクエストを変更する
のか否か及びどのように変更するのかを確定するためにマッピング規則を使用す
る。マッピング規則は１つの表現を別の表現へマップする。マッピング規則は等
号により分解され２つの側に分けられる。マッピング規則の左側は、正規表現で
あり、これは一致されるべき可変パターンの部分を定義する。マッピング規則の
正規表現は、数学及びコンピュータ科学の分野における正規表現のしかるべく定
義された規則に従っており、１実施例では、マッピング規則に使われる正規表現
は、ＵＮＩＸオペレーティングシステム（例：ｒｅｇｅｘ（５）拡張正規表現）
で正規表現に適用されているのと同じ様式で適用されている。

【０１１６】 マッピング規則の右側は置換表現（即ち、左側の正規表現に代わる表現）であ
る。置換表現では、Ｎが“１”、“２”、・・・、“９”である場合に符号＄Ｎ
は、正規表現括弧演算子（）により表現される左側のパターンの最初の１０個の
部分を表す（即ち＄１は左側の１番目のパターンを表し、＄２は左側の２番目の
パターンを表すという具合である）。

【０１１７】 ＨＴＴＰリクエストは、以下の順序で３個の部分に分割される。 エリア接頭語／文書ルート接頭語／要求されたファイルの名前 モジュール１３７は、リクエストの文書ルート接頭語及びエリア接頭語を変更
することにより、ＨＴＴＰリクエストの方向を決め直す。文書ルート接頭語は、
「文書ルート」の経路名であり、文書ルートはウェブサーバ用のソースディレク
トリである。文書ルートは、その下でウェブサーバが要求された文書を探すファ
イルシステム中のディレクトリである（但し他に指定がある場合を除く）。文書
ルートは、ウェブサーバがそのルートディレクトリを表記した形として捉えるこ
とができる。

【０１１８】 あるエリアの最上レベルが必ず文書ルートであるとは限らない。開発者は、あ
るエリアの最上レベルがウェブサーバの文書ルートに対応しないようにエリアを
設定してもよい。ウェブサーバ用の実際の文書ルートは、最上域ディレクトリの
下にディレクトリを幾つ存在させてもよい。 あるエリアについての文書ルートは特別なマッピング規則により規定される。
１実施例では、各ブランチはマッピング規則のセットを有しており、本実施例で
は、特定のブランチに沿う各エリアは、特別な“_docroot”マッピング規則によ
り規定された同一文書ルートを有する。

【０１１９】 特定ブランチの文書ルート用のマッピング規則の１例は以下の通り示される。 _docroot/directoryA/directoryB 元のＵＲＬリクエストがGET/document/index.htmlである場合、文書ルート接 頭語は、元のリクエストの１番目の“/”の直前に付け加えられる。換言すると 、接頭語“/directoryA/directoryB”が“/document/index.html”の前に付け加
えられる。

【０１２０】 文書ルート接頭語の代わりに別の接頭語を使うことが望ましい状況もある。こ
のような状況には、開発者が文書ルートディレクトリの外側にコンテンツディレ
クトリを構成する場合、コンテンツディレクトリの名前を別の名前で呼ぶ場合、
又はエリアレベルで任意変換を用いる場合が含まれる。このような特別の状況に
合わせたマッピング規則があり、リクエストがこれらの特定マッピング規則の１
つに一致する場合、マッピング規則の置換表現（右側）は、文書ルート接頭語で
はなくリクエストに付け加えられる接頭語である。例えば、以下の表現が特定の
ブランチについてのマッピング規則であると仮定しよう。 /Special(.*)=/Foo$1

【０１２１】 元のリクエストがGET/special/index/htmlである場合、“/Foo"が“/index.ht
ml"に付け加えられる。

【０１２２】 エリア接頭語は、文書ルート接頭語の前、又は適用可能な場合は文書ルート接
頭語に代わる特別接頭語の前に付け加えられる。エリア接頭語は、元のリクエス
トと共に送信された「クッキー」をデコードすることにより派生される。クッキ
ーはウェブブラウザにより記憶されている永続的な少量のデータであって、バー
チャライゼーションモジュール１３７へ送信される。クッキーは様々なタイプの
情報（ユーザのアイデンティティ、ユーザセッションのアイデンティティ（「セ
ッションＩＤ」）、ポート番号など）を含むことができるが、そのような情報の
１つにビューイング域の経路の標示がある。１実施例では、クッキーは実際のエ
リア接頭語を含んでいる。別の実施例では、バーチャライゼーションモジュール
は、セッションＩＤ又はポート番号のような別タイプの情報をクッキーから抽出
し、抽出された情報の型をエリア接頭語へマップする外部ルックアップ表中のエ
リア接頭語をルックアップする。

【０１２３】 文書ルート接頭語例を継続するため、元のリクエストと共に送られたクッキー
から派生したエリア接頭語が“/iw-mount/default/main/workarea/joe"であるな
ら、変換されたリクエストは以下の通りになろう。 GET/iw-mount/default/main/workarea/joe/directoryA/directoryB/ docume
nts/index.html.

【０１２４】 ウェブブラウザが全ＨＴＴＰリクエストをバーチャライゼーションモジュール
１３７に経路付けするか、又はその内の幾つかだけを経路付けするかは、システ
ム中のＨＴＭＬ文書内に保有されているリンクのタイプに左右される。ＨＴＭＬ
文書内に保有されているリンクには少なくとも３つのタイプ、即ち相対リンク、
絶対リンク、及び完全修飾リンクがある。完全修飾リンクは、明示プロトコル仕
様と明示ホスト名とを含むリンクで、明示ホスト名の後には文書への完全経路名
が続く。絶対リンクは、プロトコル仕様もホスト名も持たないが、文書への完全
経路名を含むリンクである。絶対リンクは通常、初期スラッシュ記号（“／”）
で始まる。相対リンクは、絶対リンクに似ているが、代わりに先頭スラッシュ記
号（“／”）により特徴付けられ、これは経路が現在の文書リンクに関係するこ
とを示す。換言すると、相対リンクは、要求された文書の実際の名前以外は、現
在の文書の同一完全経路名を有する。

【０１２５】 バーチャライゼーションモジュール１３７は、３つのタイプのリンク全てを処
理できる。システム１００内に記憶されたＨＴＭＬコンテンツが完全修飾リンク
のバーチャライゼーションを要求する場合、ウェブブラウザは全リクエストをバ
ーチャライゼーションモジュール１３７に送信するように構成される。多くの共
通ウェブブラウザは構成設定を使ってこの特性をサポートする。１実施例によれ
ば、ウェブサイトが完全修飾リンクの管理を必要としない場合、ウェブブラウザ
は絶対及び相対ＨＴＭＬリンクだけをバーチャライゼーションモジュール１３７
に送る。ウェブサーバは通常、絶対及び相対リンクがバーチャライゼーションモ
ジュール１３７に自動的に送られるようにするのに特別な構成を全く必要としな
い。

【０１２６】 図３６ａ−ｂは、絶対及び相対リクエストを取り扱うためのバーチャライゼー
ションモジュール１３７のオペレーションを示す。バーチャライゼーションモジ
ュール１３７は段階３６１０において、開発ワークステーションの１つにあるウ
ェブブラウザからＨＴＴＰリクエストを受信し、段階３６２０において当該リク
エストからユニフォームリソースロケータ（ＵＲＬ）アドレスを抽出する。バー
チャライゼーションモジュール１３７は段階３６３０において、ＵＲＬアドレス
と共に送信されているクッキーも抽出する。

【０１２７】 バーチャライゼーションモジュール１３７は段階３６４０において、リクエス
トが絶対リクエストか相対リクエストなのかを判定する。あるリクエスト実施例
で、これらのリクエストは、相対ＨＴＭＬリクエストなら、バーチャライゼーシ
ョンモジュール１３７により処理される（これはウェブブラウザにより自動的に
行なわれる）以前にエリア接頭語が既にリクエストに付け加えられている事実に
より、絶対リクエストなら、バーチャライゼーションモジュール１３７により処
理される以前にエリア接頭語が付け加えられていないという事実により、区別さ
れる。リクエストが相対リクエストの場合、当該リクエストは正しいファイルシ
ステムとディレクトリ（即ち、ビューイング文書へアクセスするためファイルシ
ステムとディレクトリ）へ方向決めされており、バーチャライゼーションモジュ
ール１３７は段階３６９０においてリクエストをウェブサーバに送る。 リクエストが絶対リクエストである場合、バーチャライゼーションモジュール
１３７は段階３６５０において、ビューイング域が沿って存在するブランチに対
応しているマッピング規則を探索し、段階３６６０において適切な接頭語（（先
に説明したように）マッピング規則に基づく文書ルート接頭語又は特別接頭語の
何れか）を選択する。バーチャライゼーションモジュール１３７は段階３６７０
において、選択された接頭語を元のリクエスト又はその一部へ適切なマッピング
規則に則り付け加える。

【０１２８】 バーチャライゼーションモジュール１３７は段階３６８０において、エリア接
頭語をクッキーから（上述のように）抽出又は派生し、それを付け加えられた接
頭語の前へ段階３６７０において付ける。リクエストの経路又はその一部はここ
で完成するので、モジュール１３７は修正されたリクエストをウェブサーバ１４
５へ経路決めする。

【０１２９】 図３７は完全修飾リンクを処理するためのバーチャライゼーションモジュール
１３７の方法を示す。バーチャライゼーションモジュール１３７は段階３７１０
において、ＨＴＴＰリクエストを開発ワークステーション１１０の１つにあるウ
ェブブラウザ１１０から受信し、段階３７２０においてＵＲＬとクッキーを当該
リクエストから抽出する。

【０１３０】 次にバーチャライゼーションモジュール１３７は段階３７３０において、マッ
ピング規則を介して完全修飾リクエストを探索し、当該リクエストがマッピング
規則の正規表現と一致するかどうかを判定する。一致しない場合、リクエストは
段階３７８０においてしかるべくウェブサーバに転送される。一致する場合、バ
ーチャライゼーションモジュール１３７は段階３７５０において、マッピング規
則に従って得た接頭語を当該リクエスト又はその一部へマッピング規則に則り付
け加える。

【０１３１】 バーチャライゼーションモジュール１３７は段階３７６０において、エリア接
頭語をクッキーから（上述のように）抽出又は派生させ、それをステップ３７５
０で付け加えられた接頭語の前へ段階３７７０において付け加える。リクエスト
の経路はここで完成するので、モジュール１３７は変更されたリクエストをウェ
ブサーバ１４５へ段階３７８０において経路決めする。 バーチャライゼーションモジュール１３７により、外部ウェブサーバからのコ
ンテンツを動的にスプライシングできる。場合によっては、ウェブサイトはシス
テム１００により管理されないコンテンツを含んでいる。これらの場合、バーチ
ャライゼーションモジュール１３７は、文書が最初に探索された場所（例：ビュ
ーイング域）にないなら、文書リクエストを外部ウェブサーバへ動的に再方向付
けすることができる。文書リクエストが、「４０４ファイルは発見されず」とい
うＨＴＴＰエラーコードと共に戻された場合、バーチャライゼーションモジュー
ル１３７はマッピング規則を探索し、そして一致するものが見つかったら、マッ
ピング規則に則ってそのリクエストを変更する。変更されたリクエストは次に特
定の外部宛先ウェブサーバに送信される。

【０１３２】 バーチャライゼーションモジュール１３７は、異なるブランチからのコンテン
ツも動的にスプライシングできる。ウェブサイトコンテンツは、異なる開発ブラ
ンチへ分離される場合もある。このような例では、バーチャライゼーションモジ
ュール１３７が「４０４ファイルは発見されず」というＨＴＴＰエラーコードを
受信するなら、バーチャライゼーションモジュール１３７は、既存の文書ルート
接頭語を別のブランチの文書ルート接頭語に置き換える。変更されたリクエスト
はここでウェブサーバ１４５に送信される。

【０１３３】 図３８は、動的サイトベース又はブランチベースのスプライシングを実行する
ためのバーチャライゼーションモジュールのオペレーションを示す。バーチャラ
イゼーションモジュール１３７は、ウェブサーバ１４５からＨＴＴＰリクエスト
の結果を受信する。バーチャライゼーションモジュールは、その結果から、要求
された文書が見つかったかどうかを確定する。見つかった場合、バーチャライゼ
ーションモジュール１３７は段階３８２５において、要求された文書を、バーチ
ャライゼーションモジュールへリクエストを送った元のウェブブラウザへ転送す
る。文書が発見されない場合は、バーチャライゼーションモジュール１３７は段
階３８３０において、マッピング規則を探索し、ウェブサーバへ送られたＨＴＴ
Ｐリクエスト又はその一部が何れかの規則の左側と一致するかどうかを段階３８
４０において判定する。一致するなら、リクエストは段階３８５０においてマッ
ピング規則に従って変更され、段階３８６０において適切なウェブサーバに転送
される。

【０１３４】 当業者には理解されるように、本発明は、その精神並びに本質的特性から逸脱
することなく他の具体的な形態に実施することができる。ウェブサイト開発は本
明細書に開示された発明の多くの実用的なアプリケーションの１つにすぎない。
本明細書に開示された発明の別のアプリケーションには、ソースコード、メディ
アファイル（例：ＣＤ−ＲＯＭマルチメディア）、メディアエンジン等を開発す
ることも含まれる。従って、本発明の開示は、冒頭の請求の範囲に述べられる本
発明の範囲を制限することではなく例示することを意図するものである。

【図面の簡単な説明】

【図１】 本発明の１実施例による、ウェブサイト開発用のコンピュータネットワークを
示す。

【図２】 本発明の１実施例による、ウェブサイトコンテンツを開発するための（開発者
の視点から見た）開発フローを示す。

【図３】 本発明の１実施例によるブランチの例を示す。

【図４】 本発明の１実施例による、メインブランチの初期コンテンツの例を示す。

【図５】 本発明の１実施例による、メインブランチの例を示す。

【図６】 本発明の１実施例による、メインブランチの別の例を示す。

【図７】 本発明の１実施例による、メインブランチとサブブランチの例を示す。

【図８】 本発明の１実施例による、エリアのディレクトリツリーの例を示す。

【図９】 本発明の１実施例による、ワークエリアオブジェクトの図的表示である。

【図１０】 本発明の１実施例による、世代ＩＤを派生するための方法を示す。

【図１１】 本発明の１実施例による、系図ツリーの例を示す。

【図１２】 本発明の１実施例による、ディレクトリの図的表示である。

【図１３】 本発明の１実施例による、ウェブサイト開発モジュールを示す。

【図１４】 本発明の１実施例による、ワークエリア作成モジュールのオペレーションを示
す。

【図１５】 本発明の１実施例による、ステージエリア作成モジュールのオペレーションを
示す。

【図１６ａ】 本発明の１実施例による、エディション作成モジュールのオペレーションを示
す。

【図１６ｂ】 本発明の１実施例による、エディション作成モジュールのオペレーションを示
す。

【図１７ａ】 本発明の１実施例によるブランチ作成モジュールのオペレーションを示す。

【図１７ｂ】 本発明の１実施例によるブランチ作成モジュールのオペレーションを示す。

【図１７ｃ】 本発明の１実施例によるブランチ作成モジュールのオペレーションを示す。

【図１８ａ】 本発明の１実施例による追加アイテムモジュールのオペレーションを示す。

【図１８ｂ】 本発明の１実施例による追加アイテムモジュールのオペレーションを示す。

【図１８ｃ】 本発明の１実施例による追加アイテムモジュールのオペレーションを示す。

【図１８ｄ】 本発明の１実施例による追加アイテムモジュールのオペレーションを示す。

【図１９】 本発明の１実施例による、追加直接リファレンスモジュールのオペレーション
を示す。

【図２０】 本発明の１実施例による、取り除き直接リファレンスモジュールのオペレーシ
ョンを示す。

【図２１ａ】 本発明の１実施例による参照カウントモジュールのオペレーションを示す。

【図２１ｂ】 本発明の１実施例による参照カウントモジュールのオペレーションを示す。

【図２２】 本発明の１実施例による、読み出しディレクトリモジュールのオペレーション
を示す。

【図２３ａ】 本発明の１実施例による、取り除きアイテムモジュールのオペレーションを示
す。

【図２３ｂ】 本発明の１実施例による、取り除きアイテムモジュールのオペレーションを示
す。

【図２４ａ】 本発明の１実施例による、エディットファイルモジュールのオペレーションを
示す。

【図２４ｂ】 本発明の１実施例による、エディットファイルモジュールのオペレーションを
示す。

【図２５】 本発明の１実施例による、再命名モジュールのオペレーションを示す。

【図２６ａ】 本発明の１実施例による、生成ディレクトリ経路モジュールのオペレーション
を示す。

【図２６ｂ】 本発明の１実施例による、生成ディレクトリ経路モジュールのオペレーション
を示す。

【図２７】 本発明の１実施例による、生成ベースネームモジュールのオペレーションを示
す。

【図２８ａ】 本発明の１実施例による、提出モジュールのオペレーションを示す。

【図２８ｂ】 本発明の１実施例による、提出モジュールのオペレーションを示す。

【図２８ｃ】 本発明の１実施例による、提出モジュールのオペレーションを示す。

【図２９】 本発明の１実施例による、矛盾照合モジュールのオペレーションを示す。

【図３０ａ】 本発明の１実施例による、比較ディレクトリモジュールのオペレーションを示
す。

【図３０ｂ】 本発明の１実施例による、比較ディレクトリモジュールのオペレーションを示
す。

【図３１ａ】 本発明の１実施例による比較ファイルモジュールのオペレーションを示す。

【図３１ｂ】 本発明の１実施例による比較ファイルモジュールのオペレーションを示す。

【図３２】 本発明の１実施例による、エリア削除モジュールのオペレーションを示す。

【図３３ａ】 本発明の１実施例による、ロックモジュールのオペレーションを示す。

【図３３ｂ】 本発明の１実施例による、ロックモジュールのオペレーションを示す。

【図３４】 本発明の１実施例による、ロックモジュールの別のオペレーションを示す。

【図３５】 本発明の１実施例による、ウェブブラウザと、ＨＴＴＰプロトコルバーチャラ
イゼーションモジュールと、ウェブサーバとの間のコミュニケーションパスを示
す。

【図３６ａ】 本発明の１実施例による、ＨＴＴＰプロトコルバーチャライゼーションモジュ
ールのオペレーションを示す。

【図３６ｂ】 本発明の１実施例による、ＨＴＴＰプロトコルバーチャライゼーションモジュ
ールのオペレーションを示す。

【図３７】 本発明の１実施例による、ＨＴＴＰプロトコルバーチャライゼーションモジュ
ールの別のオペレーションを示す。

【図３８】 本発明の１実施例による、ＨＴＴＰプロトコルバーチャライゼーションモジュ
ールの更に別のオペレーションを示す。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ， ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，Ｌ Ｔ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ， ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，Ｕ Ａ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 イェー テランス ティー ダブリュー アメリカ合衆国 カリフォルニア州 95070 サラトガ モード アベニュー 18681 (72)発明者 パーク ブリット エイチ アメリカ合衆国 カリフォルニア州 94043 マウンテン ヴィュー イージー ストリート 280−＃505 (72)発明者 バー サンフォード エル アメリカ合衆国 カリフォルニア州 94089 サニーヴェイル モース アベニ ュー 1063−＃３−307 (72)発明者 イア ジャック エス アメリカ合衆国 カリフォルニア州 95120 サン ホセ ロイヤル エイコー ン プレイス 6102 (72)発明者 ヘッジ ガジャナーナ アメリカ合衆国 カリフォルニア州 95120 サン ホセ クロスゲーツ レー ン 1325 (72)発明者 コックラン ケヴィン アメリカ合衆国 カリフォルニア州 94306 パロ アルト マッケイ ドライ ヴ 4217 Ｆターム(参考） 5B009 QB02 SA03 SA14 VC03 5B082 HA05 HA08 【要約の続き】 る。

Claims (6)

【特許請求の範囲】
1. 【請求項１】 選ばれたオブジェクトをワークエリア内で編集する段階と、 前記ワークエリアのコンテンツをステージエリアへ提出する段階と、 前記ワークエリアのコンテンツを前記ステージエリアへ提出された他のコンテ
   ンツと統合する段階と、 前記他のコンテンツが前記ワークエリアのコンテンツと矛盾しているか否かを
   判定する段階と、 前記他のコンテンツが前記ワークエリアのコンテンツと矛盾していない場合に
   は前記ステージエリアのコンテンツをウェブサイトのエディションとする段階と から成ることを特徴とするウェブサイトを開発するための方法。
2. 【請求項２】 ファイルを管理するためのシステムにおいて、 ワークエリアであって、該ワークエリア内でユーザがファイルを編集できる読
   み出しオペレーション及び書き込みオペレーションを有するファイルシステムで
   ある、ワークエリアと、 読み出しオペレーション及びバージョン化オペレーションを有し且つ前記ワー
   クエリアのコンテンツを受け取るようになっているファイルシステムであるステ
   ージエリアと、 読み出しオペレーションを有し且つ前記ステージエリアのコンテンツを受け取
   るようになっているファイルシステムであるエディションエリアと を備えることを特徴とするシステム。
3. 【請求項３】 複数のワークエリアを更に備え、前記ステージエリアが、前
   記複数のワークエリアの２つ又はそれ以上のワークエリアのコンテンツの矛盾を
   受け取り且つ照合するようになっていることを特徴とする請求項２に記載のシス
   テム。
4. 【請求項４】 複数のファイルシステムを有するシステム中で、アイテムが
   含まれる前記ファイルシステムそれぞれの前記アイテムのコンテンツのアイデン
   ティティを維持するための方法において、 履歴オブジェクトを前記アイテムと関係付ける段階と、 前記アイテムが含まれる各ファイルシステムについて、前記ファイルシステム
   中の前記アイテムに関係ある前記コンテンツを示す前記履歴オブジェクト中にエ
   ントリを維持する段階と から成ることを特徴とする方法。
5. 【請求項５】 新たなコンテンツを前記複数のファイルシステムの内の１つ
   のファイルシステム中のアイテムと関係付ける場合、前記アイテムが新たなコン
   テンツを有することを示すために、前記ファイルシステムに対応する前記履歴オ
   ブジェクト中のエントリを変更する段階と、 前記新たなコンテンツの参照を以前のコンテンツに追加する段階と を更に含むことを特徴とする請求項４に記載の方法。
6. 【請求項６】 第２のアイテムが、該第２アイテム中のコンテンツが前記ア
   イテムの以前のコンテンツであるか否かを判定することにより、前記（第１）ア
   イテムと矛盾しているか否か判定する段階を更に含むことを特徴とする請求項５
   に記載の方法。