(57)【要約】      （修正有）【課題】ウェブサイトを実際に変更することなく、変更点がウェブサイト全体の中でどう適合するかをコントリビュータが決められるウェブサイト開発方法又は装置を提供する。【解決手段】ウェブサイトのコンテンツを含むファイルを管理するシステムは、ウェブサイトに表示されるウェブコンテンツをユーザが生成して維持できるように構成されたワークエリア３１０と、ワークエリアから提出されたウェブコンテンツを、該ワークエリアのウェブコンテンツが他から提出されたウェブコンテンツとコンフリクトしない場合に受取って統合するように構成されたステージエリア３２０とを備えている。【選択図】図３
2009009590.tif 000002
【特許請求の範囲】
【請求項１】
ウェブサイトのコンテンツを含むファイルを管理するためのシステムであって、
ウェブサイトに表示されるウェブコンテンツをユーザが生成して維持できるように構成されたワークエリアであって、該ワークエリア内に配置されたウェブコンテンツを有するファイルの仮想表現をユーザが編集できる読み出しオペレーション及び書き込みオペレーションを有するファイルシステムである、前記ワークエリアと、
前記ワークエリアから提出されたウェブコンテンツを、該ワークエリアのウェブコンテンツが他から提出されたウェブコンテンツとコンフリクトしない場合に受取って統合するように構成されたステージエリアとを備え、該ステージエリアは、前記ワークエリアから提出されたウェブコンテンツのバージョンを保持するよう構成されている、
ことを特徴とするシステム。
【請求項２】
請求項１に記載のシステムにおいて、複数の異なるユーザがウェブサイトに表示されるウェブコンテンツを生成して維持できるように構成された複数のワークエリアを有し、前記ステージエリアは、前記ワークエリアで修正されたファイルのウェブコンテンツの変更を受取るように構成され且つ２つ以上のワークエリアから受取ったウェブコンテンツ内でのコンフリクトの検査を行うように構成された、ことを特徴とするシステム。
【請求項３】
ウェブコンテンツを含む複数のファイルシステムを有するシステムにおいてウェブサイトに表示されるウェブコンテンツの仮想のコピーを展開するシステムで使用するために前記ファイルシステムのそれぞれに含まれるアイテムのウェブコンテンツの履歴と先祖とを維持する方法であって、
履歴オブジェクトを、前記アイテムのウェブコンテンツの改訂履歴に関係する情報を含む第１アイテムと関連させ、
前記アイテムのウェブコンテンツの前記先祖に関係する情報を関連させ、
前記アイテムが含まれている各ファイルシステムであって当該ファイルシステムの前記第１アイテムに関連した前記ウェブコンテンツを識別する前記各ファイルシステムについて前記履歴オブジェクトにおけるエントリを維持して、他のアイテムとその関連のウェブコンテンツとのコンフリクトが突き止められる、
ことを特徴とする方法。
【請求項４】
請求項３に記載の方法において更に、
前記複数のファイルシステムの１つの新ウェブコンテンツを前記アイテムに関連させ、
前記１つのファイルシステムに対応する前記履歴オブジェクトにおけるエントリを前記アイテムが前記新ウェブコンテンツに関連させられたことを指示するように修正し、
前記新ウェブコンテンツにおいて以前のウェブコンテンツへの参照を追加する、
ことを特徴とする方法。
【請求項５】
請求項４に記載の方法において、更に、
第２アイテムが前記第１アイテムとコンフリクトするかどうかを、前記第２アイテムのウェブコンテンツが前記第１アイテムの以前のウェブコンテンツであるどうかを判定することによって、判定する、
ことを特徴とする方法。
【請求項６】
ウェブコンテンツのステージエリアに提出されたウェブコンテンツにおける潜在的コンフリクトを、ウェブコンテンツの仮想のコピーが開発されるワークエリアによって解明することでウェブサイトを開発する方法であって、
ウェブサイトに発行されるウェブコンテンツに関係するワークエリア内の選択オブジェクトに関連するデータを修正し、
前記ワークエリアによって開発されたウェブコンテンツに他のウェブコンテンツがコンフリクトするかどうかを判定し、
前記の異なるウェブコンテンツ間でのコンフリクトを解明し、
前記ワークエリアからのウェブコンテンツを、該ウェブコンテンツが発行される前に置かれるステージエリアに提出される、
ことを特徴とする方法。
【請求項７】
ウェブサイトを開発するシステムであって、
メモリ場所に形成されたワークエリアであって、該ワークエリア内のウェブコンテンツを有するファイルを編集することによってウェブコンテンツの仮想コピーをユーザが編集でき且つウェブサイト上での発行のために置かれるようにウェブコンテンツをユーザが提出できる、前記ワークエリアと、
メモリ場所に形成されたステージエリアとを備え、該ステージエリアは、ワークエリアによって提出されたウェブコンテンツを受取るように構成されて、１のワークエリアによって提出されたウェブコンテンツと当該ステージエリアに置かれた他のコンテンツとの間にコンフリクトがあるかどうかを判定し、ワークエリアのウェブコンテンツが当該ステージエリアに提出された他のコンテンツにコンフリクトしないときにはワークエリアから提出されたウェブコンテンツを統合し、ワークエリアから送られたウェブコンテンツのバージョンを維持するように構成されている、
ことを特徴とするシステム。
【請求項８】
請求項７に記載のシステムにおいて、
前記ワークエリアが、メモリ内に格納された複数のワークエリアにファイルシステムとして特徴付けられ且つユーザが当該ワークエリアにおいてウェブコンテンツを有するファイルを編集できるように読み出しオペレーション及び書き込みオペレーションを有しており、
前記ステージエリアが、複数のワークエリアで開発されたウェブコンテンツを置くためのファイルシステムであってメモリ内に格納されたファイルシステムとして特徴付けられてワークエリアからのウェブコンテンツを受取ることができ、該ステージエリアは、ワークエリアから受取ったウェブコンテンツのバージョンを維持するように構成されたバージョン機構と、ウェブコンテンツがコンフリクトしない場合に複数のワークエリアから受取ったウェブコンテンツを統合するように構成された統合機構とを備えている、
ことを特徴とするシステム。
【請求項９】
ウェブコンテンツの仮想コピーを修正するための少なくとも１つのワークエリアと１つまたはそれ以上のワークエリアから提出されたウェブコンテンツを統合すためのステージエリアとを有するウェブコンテンツ修正システムにおいて使用するように構成された、ウェブサイトのコンテンツ修正方法であって、
選択されたオブジェクトのウェブコンテンツをワークエリア内で修正し、
該ワークエリアのウェブコンテンツを、該ウェブコンテンツがステージエリアに提出された他のウェブコンテンツとコンフリクトするか否かを判定するために、分析し、
前記他のウェブコンテンツが前記ワークエリアのウェブコンテンツとコンフリクトしない場合には、それらのウェブコンテンツをステージエリアに提出し、
前記他のウェブコンテンツが前記ワークエリアのウェブコンテンツとコンフリクトする場合には、ウェブコンテンツをステージエリアに提出しない、ことから成る
ことを特徴とする方法。
【請求項１０】
請求項９に記載の方法において、更に、前記ステージエリアに提出された前記他のウェブコンテンツが前記ワークエリアのウェブコンテンツとコンフリクトする場合には、前記ウェブコンテンツがステージエリアに提出されるのを拒否することを含む、ことを特徴とする方法。
【請求項１１】
請求項９に記載の方法において、更に、前記ワークエリアによって前記ステージエリアに提出された前記他のウェブコンテンツが前記ワークエリアのウェブコンテンツとコンフリクトする場合には、前記ワークエリアの前記ウェブコンテンツを、他のウェブコンテンツとの統合のために前記ステージエリアに提出するのを保留することを含む、ことを特徴とする方法。
【請求項１２】
請求項９に記載の方法において、前記ワークエリアのウェブコンテンツを該ウェブコンテンツがステージエリアに提出された他のウェブコンテンツとコンフリクトするか否かを判定するために分析することが、
前記ワークエリアのウェブコンテンツを、該ワークエリアのウェブコンテンツが前記ステージエリアにワークエリアによって提出された他のウェブコンテンツと共通の先祖を共有するか否かを判定するように、分析することを包含し、
前記ワークエリアの前記ウェブコンテンツが前記ステージエリアにワークエリアによって提出された他のウェブコンテンツと共通の先祖を共有する場合には、コンフリクトが存在しないと判定し、
前記ワークエリアの前記ウェブコンテンツが前記他のウェブコンテンツと共通の先祖を共有しない場合には、コンフリクトが存在すると判定する、
ことを特徴とする方法。
【請求項１３】
請求項９に記載の方法において、前記ワークエリアのコンテンツを該コンテンツがステージエリアに提出された他のコンテンツとコンフリクトするか否かを判定するために分析することが、
前記ワークエリアのコンテンツを、該コンテンツが前記ステージエリアに提出された他のコンテンツと同じコンテンツか否か、及び該コンテンツが前記ステージエリアに提出された前記他のコンテンツと共通の先祖を共有するか否かを判定するように、分析することを含み、
前記ワークエリアの前記ウェブコンテンツが前記ステージエリアに提出された前記他のウェブコンテンツと同じでない場合には、コンフリクトが存在すると判定するとともに、前記ウェブコンテンツは前記ワークエリアから前記ステージエリアに提出されないようにし、
前記ワークエリアの前記ウェブコンテンツが前記ステージエリアに提出された前記他のウェブコンテンツと同じ場合には、コンフリクトが存在しないと判定するとともに、前記ウェブコンテンツが前記ワークエリアから前記ステージエリアに提出されるようにし、
前記ワークエリアの前記ウェブコンテンツが前記ステージエリアに提出された前記他のウェブコンテンツと共通の先祖を共有しない場合には、コンフリクトが存在すると判定するとともに、前記コンテンツは前記ワークエリアから前記ステージエリアに提出されないようにし、
前記ワークエリアの前記ウェブコンテンツが前記ステージエリアに提出された前記他のウェブコンテンツと共通の先祖を共有する場合には、コンフリクトが存在しないと判定するとともに、前記ウェブコンテンツが前記ワークエリアから前記ステージエリアに提出されるようにする、
ことを特徴とする方法。
【請求項１４】
ウェブサイトのコンテンツを開発して修正する少なくとも１つのワークエリアとワークエリアからのコンテンツを統合するためのステージエリアとウェブサーバとを有するシステムにおいて使用する、ウェブサイトのコンテンツを開発して維持する方法であって、
ウェブブラウザからのリクエストを受取ることと、
前記リクエストからＵＲＬを抽出することと、
前記リクエストからクッキーを抽出することと、
所定のマッピング規則のセットに従って接頭語を選択することと、
前記マッピング規則に従って前記選択した接頭語を前記元のリクエストの少なくとも１部に関連付けることによって前記ＵＲＬを、再マッピングによって生じるＵＲＬがユーザのワークエリアに対応するようにする、再マッピングすることと、
前記リクエストを前記ウェブサーバに送ることとから成る、
ことを特徴とする方法。
【請求項１５】
請求項１４に記載の方法において、更に、
前記リクエストが完全に修飾されたリクエストであるか否かを判定することと、
前記マッピング規則を、前記完全修飾リクエストに一致する接頭語を発見するように探索することとを包含し、
前記マッピング規則において接頭語との一致がある場合には、
前記マッピング規則に従って、前記リクエストの少なくとも１部に接頭語を付けることと、
前記クッキーからエリア接頭語を抽出することと、
前記クッキーからのエリア接頭語を、前記マッピング規則に一致した接頭語に付けて、生じるＵＲＬがユーザのワークエリアに対応するようにすることと、
前記リクエストを前記ウェブサーバに送ることとを包含し、
前記一致がない場合には、
前記リクエストを前記ウェブサーバに送ることを包含する、
ことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的には階層的ファイルシステムに関する。より厳密には、ウェブサイトを開発するツールとして使用できる、ファイル管理のためのシステムと方法に関する。
【背景技術】
【０００２】
インタネットは商業的に大きな役割を果たしており、多くの会社がウェブサイトを所有する傾向にある。多くのウェブサイトはしばしば修正する必要があり、通常は数十人のコントリビュータの手で特別なプロセスによって修正される。それ故、ウェブサイトのコンテンツを更新し、正確にし、良好に統合された状態に維持するための継続的プロセスは、初期計画及び開発のフェーズでのプロセスよりもしばしば大きな課題となる。インタネットは数百にも及ぶチームによって、日毎、時間毎、又は分毎に更新される。同様に、イントラネットのコンテンツのコントリビュータは新たなコンテンツを絶えず提出したり又は既存コンテンツに変更したりするので、新たなコンテンツを素早く組み込まないと、基本的な通信リソースとしてのイントラネットの有用性は限定されてしまう。
【０００３】
大型ウェブサイトは、ウェブコントリビュータの数が指数的に増加すると、多くの問題に直面する。これらのサイトの規模とコンテンツは急速に増加しつづけており、サイトの通信量とインタネット商取引が増えるにつれ、より頻繁な更新が必要となる。コントリビュータ、量、コンテンツの複雑さが増すにつれ、各変更を監督し品質を管理することはウェブサイトの管理者（「ウェブマスタ」）にとってますます困難となるに至った。
【０００４】
ウェブサイトの開発は複雑なので、ウェブサイト開発を監督／管理する中央システムが必要となる。ウェブサイトの開発を監督／管理するための既存のシステムには、ソフトウェア構成監督システム、ドキュメント監督システム、データベース発行システムが含まれている。
【０００５】
【特許文献１】特開平９−１３８７９３号公報
【非特許文献１】雑誌「ＵＮＩＸ  ＭＡＧＡＺＩＮＥ」第１２巻第１２号の記事「ＵＮＩＸ知恵袋３３  ＣＶＳ」
【非特許文献２】雑誌「ＵＮＩＸ  ＭＡＧＡＺＩＮＥ」第１３巻第１号の記事「ＵＮＩＸ知恵袋３４  ＣＶＳ（２）」
【発明の開示】
【発明が解決しようとする課題】
【０００６】
このような既存のウェブサイト開発システムには、不利な点が幾つかある。例えば、ウェブサイトを維持するには数十人又は数百人の手を煩わすことが必要なので、ウェブサイトコントリビュータを並列に作業させることが望ましい。ソフトウェア構成監督システムは、複数のコントリビュータがウェブサイトの同一エリアを変更することを許さない。更に、既存のシステムでは何れも、並行に作業するコントリビュータがウェブサイトを実際に変更することなく自分の作業を別々にテストすることを許さない。従って、コンフリクト（矛盾：本書ではコンフリクトという）する変更がウェブサイトに寄せられ、ウェブサイトにエラーを生じさせることもある。
【０００７】
コントリビュータは自分の作業が他のコントリビュータの作業と組み合わされた際にどんな影響があるのか個別のレベルで予測することができないので、既知のシステムでは、ウェブマスタがウェブサイトに寄せられた全ての変更点を統合してエラーをチェックすることに依存している。ウェブマスタは又、変更を認められたコントリビュータがコンテンツを変更することを保証している。しかし、ウェブマスタは、ウェブサイトの変更に関する統合と試験を全て行わねばならないので、しばしばウェブサイトを開発するプロセスのボトルネックとなる。複数のユーザの作業を統合することは人手を介してなされ時間も掛かり、バグの判定及びコンフリクト（矛盾）点の解決に膨大な時間が浪費されるのに対し、システムの設計、改革、戦略には殆ど時間が掛けられていない。更にウェブマスタは、コントリビュータが変更点をウェブマスタへ提出する準備が整うまで、コントリビュータの変更の進展度合を容易には監督することができない。従って、ウェブマスタは、早い段階でエラーを正すこともできなければ、コントリビュータがどの位進展しているかを判定することもできない。
【０００８】
既知のウェブサイト開発システムの別の欠点は、ファイルバージョンの履歴を追跡しない点である。ウェブサイトのファイルは常に追加、除去、変更、移動、再命名されているので、誰がどんなファイルバージョンを作ったか、バージョンは何時作られたかを知ることが有効である。以前のバージョンへ完全にアクセスすることにより、ユーザは、バグを生じさせた変更を容易に見つけ、過去のバージョンに立ち戻り、新たなバグを特定することができる。更に、既知のウェブサイト開発システムでは、サイトの一部又は全体についての如何なる過去のバージョンへも直接アクセスすることができない。ウェブサイトの任意の過去のバージョンへ直接立ち戻れることは、サイトエラーが起きたり又は不適切又は不正確な情報が配分されたりした場合に惨事から回復するための不可欠なツールとなる。
【０００９】
従って、ウェブサイトを実際に変更することなく、変更点がウェブサイト全体の中でどう適合するかをコントリビュータが決められるウェブサイト開発システムが求められている。更に、コントリビュータがファイルの初期バージョン、ウェブサイトのサブセクション又はウェブサイトへアクセスでき、且つ、ウェブマスタがウェブサイトをより容易に変更できると同時にコントリビュータの進展状況をチェックできるウェブサイト開発システムが求められている。
【課題を解決するための手段】
【００１０】
本発明は、ファイル管理のためのシステムと方法を提供する。このようなシステムの１つの使い方は、ウェブサイト開発ツールとしての使い方である。
【００１１】
本発明のシステムは、本明細書で「エリア」と呼ばれる階層的ファイルシステムで構成される。エリアには、ワークエリア、ステージエリア、エディションエリアの３タイプがある。ワークエリアは、修正可能なファイルシステムエリアであり、このワークエリアでユーザは、ファイル及びディレクトリの作成、編集、削除、追加，修正を行うことができる。１実施形態では、ワークエリアは既存ウェブサイトの仮想的なコピーであり、ウェブサイトに関するユーザの個人的見解である。
【００１２】
ステージエリアは、選択されたバージョン化オペレーションをサポートする読み出し専用ファイルシステムである。ワークエリアの様々なユーザは、自分達のワークエリアのコンテンツをステージエリアに提出することによって、自分達のワークを統合化することができる。ステージエリアにおいて、開発者は、自分達のワークを比較し、自分達の変更点がどのように適合しているかを知ることができる。
【００１３】
エディションエリアは読み出し専用ファイルシステムである。ステージエリアのコンテンツは仮想的にエディションエリアへコピーされ、ステージエリアのコンテンツの固定された読み出し専用のスナップショットが生成される。１実施形態では、エディションエリアのコンテンツは、ウェブサイトのエディションのコンテンツを表す。
【００１４】
１実施形態では、複数のエリアはディレクトリツリーを共有し、エリアが作成される毎にディレクトリ及びファイルを物理的にコピーする必要はない。これにより、エリアを素早く作成することができ、システムリソースを有効に利用できる。ファイル又はディレクトリのコンテンツに関する情報を記憶する履歴オブジェクトは、ファイル又はディレクトリが存在する各エリア中の各ファイル又はディレクトリと関係付けられている。
【００１５】
別の実施形態では、本発明は各ファイル及びディレクトリのコンテンツの履歴を追跡する。これにより、システムはファイル同志を又はディレクトリ同志を容易に比べることができ、それらが同一なのか又は関係付けられているのかを識別することができる。
【００１６】
更に別の実施形態では、本発明のシステムは、１つのウェブサーバを複数のウェブサーバであるかのように作動させることのできるＨＴＴＰプロトコルバーチャライゼーションモジュールを含んでいる。これにより、各エリアはエリア毎に個別のウェブサーバを持つことなく、ＨＴＴＰプロトコルレベルにおける完全なウェブサイトになることができる。
【発明を実施するための最良の形態】
【００１７】
本発明をウェブサイト開発と関連付けて以下に説明するが、当該技術分野に詳しい当業者に理解されているように、本発明は他の具体的な形でも実現することができる。
【００１８】
図１は、ウェブサイト開発用のコンピュータネットワーク１００を示す。従来型のパソコンである開発ワークステーション１１０上で、ウェブサイト開発者はウェブサイト用のファイルを追加し、除去し、編集し、検査する。開発ワークステーション１１０は、インタネットのようなコンピュータネットワーク１２０を介して開発サーバ１３０に接続される。
【００１９】
開発サーバ１３０は、ウェブサイトコンテンツを求める開発ワークステーション１１０からのＨＴＴＰ要求を処理するウェブサーバ１４５を含んでいる。開発サーバ１３０は、マイクロソフト社から商業的に入手可能なウインドウズＮＴファイルシステムのような従来型の支援記憶装置１６０も含んでおり、そこには、ＷＳファイルが物理的に記憶されている。
【００２０】
開発サーバ１３０は、ウェブサイト開発ソフトウェアモジュール１３５を実行することによって本発明のウェブサイト開発方法を実現する従来型のメモリ１５０（すなわち、ＲＡＭ）及び従来型プロセッサも含んでいる。以下に述べるウェブサイト開発モジュールはメモリ１５０に記憶される。メモリ1５０には、ウェブサーバ１４５を複数のウェブサーバの如く作動させる以下に述べるＨＴＴＰプロトコルバーチャライゼーションモジュール１３７も記憶されている。
【００２１】
開発サーバ１３０は、ネットワーク１６５を介してプロダクションウェブサーバ１７０に連結される。ネットワーク１６５はネットワーク１２０のような同じネットワークでも、別のネットワークでもよい。ウェブサイトプロダクションウェブサーバ１７０はインタネット又はイントラネット１７５へ連結されており、あるウェブサイトをワールドワイドウェブ又はイントラネットへ通知する準備が整うと、開発サーバ１３０は当該ウェブサイトをプロダクションウェブサーバ１７０へ送り、プロダクションウェブサーバ１７０は、インタネット又はイントラネットへのアクセスを当該ウェブサイトへ提供する。
【００２２】
ウェブサイトは任意のファイルシステムのコンテンツで構成される。本発明のウェブサイト開発システムは階層的ファイルシステムの集合から構成される。これらファイルシステムのそれぞれは、個別のファイルを管理する環境であり、個別ファイルを操作するための手段を提供する。実行時に、ウェブサイト開発ソフトウェアモジュール１３５は、ファイルの管理と操作の大部分を行うことのできるファイルシステムの一部となる。支援記憶装置１６０には、ファイル及び対応するメタデータ（例えば、オーナーＩＤ、グループＩＤ、アクセスコントロールファイル名、修正回数、作成回数等）が物理的に記憶される。１実施形態では、ファイルは（支援記憶装置１６０中に物理的に記憶されていても）支援記憶装置１６０以外のドライブに記憶されているように見えるようにすることができる。
【００２３】
階層的ファイルシステムは、ファイルとシンボルリンクを有するディレクトリツリーを備えている。ディレクトリツリーの頂点にはルートディレクトリが存在し、ここから他の全てのディレクトリが直接的に又は間接的に派生する。
【００２４】
ファイルシステムは、修正可能システム又は読み出し専用システムである。修正可能ファイルシステムは、ファイル上の読み出しオペレーション（即ち、ルートディレクトリ取得、ディレクトリ読み出し、ディレクトリ参照、ファイル読み出し、属性取得、シンボルリンク読み出し等）をサポートし、オペレーション（即ち、ディレクトリ作成、ファイル作成、シンボルリンク作成、属性セット、ファイル除去、ディレクトリ除去、ファイル再命名、ディレクトリ再命名、ファイル書込等）を修正するファイルシステムである。
【００２５】
読み出し専用ファイルシステムは、読み出しオペレーションのみを支援する。読み出し専用ファイルシステムとしては、ＣＤＲＯＭボリュームと、書き込みタブがライトプロテクト位置にあるフレキシブルディスクボリュームとの２つの例を挙げることができる。
【００２６】
上記のように、本発明のウェブサイト開発システムは、階層的ファイルシステムから構成される。階層的ファイルシステムの幾つかは、ウェブサイトのコンテンツを構成するファイルを生成するように修正することができる。他のファルシステムは、ウェブサイト開発に協調させるために他のファルシステムからのファイルを比較することができ、更に別のファルシステムは、ウェブサイトのコンテンツを構成する完成したファイルを含んでいる。
【００２７】
本発明の階層的ファイルシステムが従来のファイルシステムと異なる１つの点は、読み出し及び／又は修正オペレ−ションに加えて、本発明のファイルシステムの幾つかが、以下に述べるように２つ又はそれ以上の関係ファイルシステムを操作できる選択されたバージョン化オペレーションをサポートする点である。ウェブサイトのコンテンツは、本発明の関連ファイルシステムの集合上で読み出しオペレーション、修正オペレーション、バージョン化オペレーションを実行することにより作成される。
【００２８】
本発明の階層的ファイルシステムは「エリア」と呼ばれ、ワークエリア、ステージエリア、エディションエリアの３タイプのエリアがある。ワークエリアは、修正可能なファイルシステムであるが、ステージエリアとエディションエリアは読み出し専用ファイルシステムである。
【００２９】
ワークエリアは、既存のウェブサイトの仮想的なコピーとして始まる（既存システムが存在しない場合を除く。存在しない場合には、ワークエリアは空の状態から始まる）。換言すると、ワークエリアは、ウェブサイトとして指定されたファイルシステムと同じコンテンツを有して始まる。ワークエリアは、ウェブサイトに関する開発者の個人的な見解であり、ウェブサイトに寄稿する各開発者はワークエリアへ寄稿をしているのである。ワークエリア中で、開発者はウェブサイトコンテンツを自由に追加、削除、修正することができ、自分の変更がウェブサイト全体のコンテキスト中でどう適合するかを知ることができる。追加、削除、修正のオペレーションの詳細を以下に述べる。あるコントリビュータがあるワークエリアで行った変更は、他のコントリビュータが他のワークエリアで行ったワークには影響しない。これは、以下に述べるように各エリアが別のファイルシステムとなっているからである。
【００３０】
開発者は、自分達のワークエリアのコンテンツをステージエリアへ提出することにより、自分達のワークをステージエリアで統合する。提出オペレーションとは、上記の選択されたバージョン化オペレーションの1つであり、以下に更に詳しく述べる。ステージエリアは、ブランチ（ブランチは以下に詳述）上の全ユーザが入手できるウェブサイトに関する共有の見解である。換言すると、ステージエリアは、ブランチに沿って全ユーザがアクセスすることができるファイルシステムである。ステージエリアは、複数の開発者のワークエリアの集合的ワークエリアを保持し、このステージエリアによって開発者は自分達の変更を共有し統合化することができる。ステージエリアにおいて、開発者は自分達のワークを比較し、自分達の変更がどのように適合するかを知ることができる。比較オペレーションは、以下に詳述する選択されたバージョン化オペレーションの別のオペレーションである。
【００３１】
ステージエリアにおける集合的ワークは、別のコントリビュータがワークエリアから新たなコンテンツを提出するにつれて変化するステージエリアの現状態にワークエリアを更新するために、個人のワークエリアへ仮想的にコピーし直すことができる。エリアはディレクトリツリーを共有し、ディレクトリツリーを物理的にコピーする必要がないようになっているので、コピーは「仮想的」である。
ステージエリアにおける集合的ワークが最終的なものと見なされると、そのコンテンツが発行されウェブサイトのエディションが作成される。
【００３２】
エディションからワークエリアを作成する段階と、ステージエリアを発行する段階とは、以下に述べる選択されたバージョン化オペレーションの追加オペレーションである。
【００３３】
ステージエリアのコンテンツは、エディションエリアへ仮想的にコピーされ、ウェブサイトのエディションが作成される。ここでも仮想的コピーは、エディションがステージエリアの場合のように同じディレクトリツリーを参照することを意味している。エディションは読み出し専用ファイルシステムであるので、エディションは、単一ブランチに沿った特定の点におけるウェブサイト全体のコンテンツの固定されたスナップショットである。各エディションは記録され全開発者がアクセスできる。
【００３４】
エディションのコンテンツはワークエリアへ仮想的にコピーし直すことが可能で、ウェブサイトを更に開発するベースとして使うことができる。エディションは又、記録としての役割を果たし、ユーザはファイルやディレクトリを瞬間的に呼び戻し、ウェブサイトの過去の全バージョンを再構成することができる。
【００３５】
図２は本発明のある開発者の視点から見たワークエリアからエディションまでの開発フローを要約したものである。開発者は段階２１０において、ワークエリアでファイルを編集、追加、削除する。次に開発者は段階２２０において、自分のワークエリアのコンテンツをステージエリアへ提出する。ステージエリアで、コントリビュータのワークエリアのコンテンツは段階２３０において、他のコントリビュータのワークエリアのコンテンツと統合される。段階２４０において、ステージエリアへ提出された全てのコンテンツが良好に統合され承認されると、ステージエリアのコンテンツは段階２５０において、エディションとして発行される。発行されなければ、コントリビュータは、自分のファイルが承認されるまで、段階２１０において編集を継続する。
【００３６】
１実施形態によれば、ウェブサイト開発は開発の幾つかのブランチに沿って分割することができる。開発者の視点からすると、ブランチとは単一のウェブサイトの開発経路である。図３に示すように、単一のブランチ３００は、ワークエリア３１０、ステージエリア３２０、１つ又はそれ以上の記録されたウェブサイトエディション３３０を含んでいる。ブランチは、開発チームが互いに別の代わりの開発パスを保持できるように、サブブランチを含むことができる。コンテンツはブランチ、サブブランチの間で共有することができる。
【００３７】
ウェブサイト開発をブランチに沿って分割するある例では、現在のウェブサイトのために１つのブランチを有し且つウェブサイトの新たなバージョンのために別のブランチを有している。別の例では、特定の領域又はクライアント用にウェブサイトを誂えるために、別の領域又は別のクライアントのために別の開発ブランチを有している。
【００３８】
ウェブサイト開発ソフトウェアモジュールが開発サーバにインストールされた時に、メインブランチは生成される。図４に示すように、メインブランチ４００は最初、空のステージエリア４２０と空のエディション４３０とを含む。メインブランチは最初、空のワークエリア４１０も含んでいる。ワークエリアは、メインブランチが作成される時、又は、ワークエリアの属性を定義する準備が整うまでワークエリアの生成を遅らせたいとユーザが思う暫く後の時（人々がワークエリアへアクセスできる時）に生成することができる。
【００３９】
ウェブサイト開発ソフトウェアモジュール以前から存在していたウェブサイトがインストールされる場合、ワークエリアが事前に存在していなければ、空のワークエリア４１０が生成される。図５に示すように、元のウェブサイトのコンテンツ５１０は、空のワークエリア４１０へコピーされ、次に空のステージエリア４２０へコピーされ、次に初期エディション４４０へ発行される。
【００４０】
追加のワークエリアは、最も新しいエディションのコンテンツを新たなワークエリアへ仮想的にコピーすることにより、メインブランチとは別の形で作成することができる。図６は、エディション４４０からメインブランチ上に３個のワークエリア６００が生成されることを示す。ワークエリア６００のコンテンツはステージエリア６１０へ提出され、ステージエリア６１０のコンテンツは新たなエディション６２０へ発行される。
【００４１】
サブブランチも、又、メインブランチ又は他のブランチと別の形で作成することができる。図７はサブブランチがメインブランチと別の形で作成されることを示す。親ブランチ７２０からのエディション７１０が、サブブランチ７３０用の初期エディション７２５として使われる。初期エディション７２５のコンテンツは次に、ワークエリア７４０、ステージエリア７５０、サブブランチ７３０の新たなエディション７６０へと、仮想的にコピーされる。サブブランチは他のサブブランチと別の形で同様に作成できることに注目されたい。サブブランチ上でのワークは、高次のブランチ上でのワークと並行且つ独立に起こる。
【００４２】
サブブランチ上で生成されたワークは、サブブランチ上のエディションのコンテンツを高次ブランチ上のワークエリアへ仮想的にコピーすることにより、高次レベルのブランチへ組み込むことができる。サブブランチからのコンテンツは、他のワークエリアからのコンテンツと統合され、高次のブランチの新たなエディションとして発行される。
【００４３】
ウェブサイト開発システムの概要と代表的な使い方を述べたので、１実施形態によるシステムの具体的な実行について述べる。
【００４４】
各々の独立したワークエリア、ステージエリア、エディションエリアは、ツリー構造に組織化された１つ又はそれ以上のファイル及びディレクトリから構成される。図８は、ディレクトリ１をルートディレクトリとしたエリアのディレクトリの例を示す。エリアは同じディレクトリツリーを共有することができる。実際に、既存エリアがコピーされて新たなエリアが作られる場合、新たなエリアは、既存エリアとしての同じルートディレクトリを参照するだけである。
【００４５】
各々の独立したワークエリア、ステージエリア及びエディションエリアは、エリアを表し、且つ、ネームフィールド、オブジェクトＩＤフィールド、世代ＩＤフィールド、ディレクトリフィールド及びブランチフィールドを有するオブジェクトを生成することによって、生成される。ネームフィールドは、ワークエリアの名前を含んでいる。ディレクトリフィールドは、特定のワークエリア、ステージエリア、エディションエリアのディレクトリツリーのルートディレクトリを識別する。ブランチフィールドは、ワークエリアがどのブランチに沿って存在するかを表す。図９はワークエリアオブジェクトの図形的に表したものである。ワークエリアを生成する際、ワークエリアオブジェクトが既存のディレクトリツリーを指示するので、ディレクトリツリーの仮想コピーは実際のコピーに相対するものとして作られることに注目されたい。
【００４６】
各々のワークエリア、ステージエリア、エディションエリアは、２つの固有の識別子を有し、本アプリケーションでは、一方を「世代ＩＤ」、他方を「オブジェクトＩＤ」と呼ぶ。オブジェクトＩＤはエリアを表すオブジェクトを識別し、一旦オブジェクトＩＤがあるオブジェクトに割り当てられると、このオブジェクトＩＤは変更されることがない。各エリアは又、あるエリアが他のエリアとどのように関連しているかを示す固有の世代ＩＤによっても識別される。特定のエリアの世代ＩＤは、以下に述べるように（例えば、ステージエリアがエディションへ発行される時）変更することができる。世代ＩＤは世代ＩＤフィールドに配置されている。オブジェクトＩＤはオブジェクトＩＤフィールドに配置されている。
【００４７】
ディレクトリ、ファイル、履歴オブジェクト（以下に述べる）、及び他のオブジェクトにも、一旦割り当てられると変更されることのないオブジェクトＩＤが割り当てられることに注目されたい。
【００４８】
世代ＩＤは、数字からなる固有のシーケンス又はセットから構成される。世代ＩＤは、エリアを固有に識別するだけでなく、上記のように、あるエリアが他のエリアとどのように関連しているかを示す。
【００４９】
エリアの1つが直接又は間接に他のエリアから派生している場合、あるエリアは別のエリアに関係している。例えば、図７において、サブブランチの初期エディションは、親ブランチのエディション２から直接派生している。サブブランチのワークエリアは、サブブランチの初期エディションから直接派生し、親ブランチのエディション２から間接的に派生している。
【００５０】
世代ＩＤは、世代ＩＤに固有な番号と、世代ＩＤを派生する世代ＩＤの数字とを含んでいる。例えば、番号１があるエリアへ割り当てられた固有番号で、番号０が別のエリアへ割り当てられた固有番号である場合、これらのエリアから派生されたあるエリアの世代ＩＤは、番号０と１と同様に例えば、自身の固有番号例えば４である。
【００５１】
図１０は、親世代ＩＤが新たなエリアの直接の親へ割り当てられる場合について、親世代ＩＤから新たなエリアへ割り当てられる世代ＩＤを派生するための方法を示す。ある固有番号が段階１０００において、連続的に（例えば、１、２、３、４）又は無作為に数字を生成するための従来のアルゴリズムを使って得られる。次に、親世代ＩＤに関連する固有数字のセット又はシーケンスが段階１０１０において検索される。次いで、親世代ＩＤと丁度今発行された固有番号を連結する数字のセット又はシーケンスが、段階１０２０で生成される。
【００５２】
エリア間の関係も系図ツリーで表される。系図ツリーはデータ構造であり、ツリーの各ノードは異なる世代を表している（例：エリア。本アプリケーションエリアを通じてエリアをしばしば世代と呼んでいることに注意されたい）。
【００５３】
図11は系図ツリーの例を表している。世代Ｇ０は初期エディションを表す。世代Ｇ２はあるワークエリア（「ワークエリア１」）を表し、世代Ｇ３は別のワークエリア（「ワークエリア２」）を表し、世代Ｇ１はあるエディション（「エディション１」）を表し、世代Ｇ４はステージエリアを表している。系図ツリーはＧ１、Ｇ２、Ｇ３がＧ０から直接派生されたことを示し、これはＧ１、Ｇ２、Ｇ３がＧ０として同一のルートディレクトリを有することを意味する。Ｇ４はＧ０から間接的に派生され、Ｇ１から直接的に派生されており、それ故にＧ０として同一のルートディレクトリを有する。
【００５４】
図１２はディレクトリ１２００を図形的に表示している。ディレクトリが変更された世代毎に、ディレクトリは世代ページ１２８０を含んでおり、この世代ページ１２８０は、世代ページ１２８０に対応する世代でのディレクトリコンテンツを掲げるオブジェクトである。従ってディレクトリは、ディレクトリが変更された各世代におけるディレクトリコンテンツのスナップショットを含んでいる。
たとえディレクトリが別のエリアに別のコンテンツを有していても、世代ページ１２８０により別のエリアは同じディレクトリを参照することができる。
【００５５】
図１２に示したディレクトリ１２００で、ディレクトリページ１２８０は、アイテム「ｍ」が世代Ｇ０でディレクトリ１２００へ加えられたこと、アイテム「ｎ」が世代Ｇ２でディレクトリ１２００へ加えられたこと、アイテム「ｐ」が世代Ｇ３でディレクトリ１２００へ加えられたことを示している。如何なるものもディレクトリ１２００から除去されなかったと仮定すると、ディレクトリページ１２８０は、特定の世代で加えられたコンテンツを含むだけでなく、特定の世代から派生された世代で加えられたコンテンツも含んでいる。例えば、図１０の系図ツリーをこの例に当てはめるとしよう。世代Ｇ０において、ディレクトリｄ１はアイテム「ｍ」を含んでいる。世代Ｇ２において、アイテム「ｎ」がディレクトリ１２００に加えられており、従って、Ｇ２はＧ０から派生しているので、ディレクトリ１２００は世代Ｇ２において、アイテム「ｍ」と「ｎ」を含んでいる（「ｍ」は除去されてないと仮定する）。世代Ｇ３において、アイテム「ｐ」がディレクトリｄ１に加えられるので、ディレクトリ１２００はアイテム「ｐ」と「ｍ」を含んでいる。Ｇ３はＧ２から派生されたのではないので、結果的にディレクトリ１２００は世代Ｇ３において、アイテム「ｎ」を含んでいない。
【００５６】
１実施形態では、ディレクトリが特定の世代で変更されてない場合、当該ディレクトリは当該世代の世代ページを含まないことになる。ディレクトリはある世代で変更されると、当該世代に関する世代ページがディレクトリへ加えられる。
【００５７】
ディレクトリ中の各アイテムは履歴オブジェクトに関係している。履歴オブジェクトは、ファイル又はディレクトリのコンテンツが編集又は修正された世代を示す。換言すると、履歴オブジェクトはディレクトリ中におけるアイテムの履歴を示している。履歴オブジェクトは、世代ＩＤのフィールド１２２５と、ファイル又はディレクトリへのポインタのコンテンツフィールド１２３０とを含んでいる。図１２に示した例では、履歴オブジェクトｈ０は、世代ｇ０においてアイテムｎがファイルｆ１に関係するコンテンツを含んでいることを示す。履歴オブジェクトｈ０は又、世代Ｇ２においてアイテムｎがファイルｆ２（ファイルｆ１ではなく）に関係するコンテンツを含んでいることを示す。コンテンツフィールド１２３０に掲げられたアイテムは、ファイルｆ２の実際のコンテンツを指している。ｆ２がディレクトリであったとすると、ｆ２はディレクトリ１２００のような別のディレクトリを指すことになろう。コンテンツには、ディレクトリに掲げられたアイテムに関係して先行するファイル又はディレクトリへのポインタを有する「以前のフィールド」１２４０が含まれている。例えば、ｆ２は、ｆ１へのポインタ１２４０と同時に、世代Ｇ２に先行してアイテム「ｍ」がｆ１のコンテンツを有していたことを意味するコンテンツ「Ｂ」を有するファイルを指す。
【００５８】
図１３は、ワークエリア、ステージエリア、エディションエリアの生成と操作を可能にする本発明の１実施形態によるウェブサイト開発ソフトウェアモジュール１３５を示す。ウェブサイト開発ソフトウェアモジュール１３５は、ワークフローサブシステム１３００、バージョン化サブシステム１３０５、オブジェクトサブシステム１３１０を含んでいる。ワークフローサブシステムは、ワークエリア、ステージエリア、エディションエリア、ブランチを生成し管理する。バージョン化サブシステムは、ファイル及びディレクトリの修正及び編集、ファイルの比較、ディレクトリの比較、ワークエリアのコンテンツのステージエリアへの提出、コンフリクト（矛盾）点に関するファイル及びディレクトリの照合等の機能を管理して制御する。オブジェクトサブシステムは、サーバのメインメモリ中及びディスク中におけるオブジェクトの配分を管理する。オブジェクトサブシステムは、従来継続型のオブジェクト記憶及びキャッシュサブシステムとして実行されてもよい。
【００５９】
ワークフローサブシステムはワークエリア生成モジュール１３１２、ステージエリア生成モジュール１３１４、エディションエリア生成モジュール１３１６、ブランチ生成モジュール１３４６、エリア削除モジュール１３４２を含む。バージョン化サブシステム１３０５は、提出モジュール１３３６、コンフリクト（矛盾）照合モジュール１３３８、比較モジュール１３４０、追加アイテムモジュール１３１８、参照カウントモジュール１３２０、追加直接参照モジュール１３２２、取り除き直接参照モジュール１３２４、読み出しディレクトリモジュール１３２６、取り除きアイテムモジュール１３２８、エディットファイルモジュール１３３０、再命名モジュール１３３２、世代ディレクトリ経路モジュール１３３４、ロックモジュール１３４４、世代ＩＤモジュール１３４８を含んでいる。ワークフローサブシステム及びバージョン化サブシステムのこれらのモジュールによって、エリア、ファイル、ディレクトリ、及びウェブサイト開発に使われる他のオブジェクトの作成と操作ができるようになる。
【００６０】
ワークフローサブシステム及びバージョン化サブシステムは、Ｃ＋＋プログラミング言語で実行される。ワークフローサブシステム及びバージョン化サブシステムのモジュールのオペレーションを以下に述べる。
【００６１】
上記のようにワークエリアは、以前のエディションのコンテンツをワークエリアへ仮想的にコピーすることによって作成される（メインブランチ上の最初のワークエリアが初期において空状態にある場合は例外とする）。図１４は、任意に「エディションｅ」と名付けられたあるエディションからワークエリアを作成するためのワークエリア生成モジュール１３１２のオペレーションを示す。モジュール１３１２は段階１４１０において、ルートディレクトリとエディションｅの世代ＩＤとを取得する。次に、モジュール１３１２は段階１４２０において、世代ＩＤモジュール１３４８から新たな世代ＩＤを取得するが、このＩＤはエディションｅの世代ＩＤから派生されたものである。世代ＩＤモジュール１３４８は新たな世代ＩＤを、図１１に示したプロセスを実行することにより派生する。モジュール１３１２は又、ワークエリア用の新たなオブジェクトＩＤ（無作為又は連続的に生成された固有の数）も取得する
【００６２】
モジュール１３１２は段階１４３０において、ワークエリアを表し且つネームフィールド、ルートディレクトリフィールド、オブジェクトＩＤフィールド、世代ＩＤフィールド、ブランチフィールドを有するオブジェクトを作成する。モジュール１３１２は段階１４４０で、ワークエリアの名前をネームフィールドへ、エディションｅのルートディレクトリをルートディレクトリフィールドへ、段階１４２０で派生された世代ＩＤを世代ＩＤフィールドへ、オブジェクトＩＤをオブジェクトＩＤフィールドへ、ワークエリアが存在するブランチＩＤをブランチフィールドへ入れる。こうしてオブジェクトは、ワークエリアが、エディションｅの同じルートディレクトリを有し且つ派生された世代ＩＤを有するデータ構造であることを示す。ワークエリアを作成するためにエディションｅのコンテンツが物理的にコピーされているのではないことに注目されたい。むしろ、新たに作成されたワークエリアは初期にはエディションｅと同じデータ構造を有していることを示すオブジェクトが作成されたのである。
【００６３】
図１５は、エディションｅと呼ばれるエディションからステージエリアを作成するためのステージエリア生成モジュール１３１４のオペレーションを示す。ステージエリアを作成するため、モジュール１３１４は段階１５１０において、エディションｅの世代ＩＤを取得し、次に段階１５２０において、エディションｅの世代ＩＤから派生された新たな世代ＩＤを世代ＩＤモジュール１３４８から取得する。モジュール１３１４は又、ステージエリアのための新たなオブジェクトＩＤ（無作為又は連続的に生成された固有の数）も取得する。
【００６４】
モジュール１３１４は、ステージエリアを表し且つネームフィールド、ルートディレクトリフィールド、世代ＩＤフィールド、オブジェクトＩＤフィールド、ブランチフィールドを有するオブジェクトを作成する。モジュール１３１４は段階１５４０において、ステージエリアの名前をネームフィールドへ、エディションｅのルートディレクトリをルートディレクトリフィールドへ、段階１５２０で得られた世代ＩＤを世代ＩＤフィールドへ、段階１５２５で得られたオブジェクトＩＤをオブジェクトＩＤフィールドへ、ステージエリアが存在するブランチＩＤをブランチフィールドへ入れる。
【００６５】
複数のステージエリアを有することの望ましいことが時にはある。例えば、公のステージエリアに加えて、選ばれたユーザのみがコンテンツを提出できる数個の私的なステージエリアを有することが望ましい。複数のステージエリアは、上記のステージエリア作成方法を複数回実行することによって作成することができる。
【００６６】
図１６Ａ−Ｂは、任意に「ｓ」とラベル付けされたステージエリアのコンテンツからエディションを作成するためのエディションエリア生成モジュール１３１６のオペレーションを示す。モジュール１３１６は段階１６１０において、世代ＩＤとステージエリア「ｓ」のルートディレクトリとを取得する。モジュール１３１６は段階１６１５において、エディションｅの固有オブジェクトＩＤも取得する。モジュール１３１６は段階１６２０において、新たなエディションを表し且つネームフィールド、ルートディレクトリフィールド、世代ＩＤフィールド、オブジェクトＩＤフィールド、ブランチフィールドを有するオブジェクトを作成する。モジュール１３１６は段階１６３０において、新たなエディションの名前をネームフィールドへ、ステージエリアの世代ＩＤを世代ＩＤフィールドへ、ステージエリア「ｓ」のルートディレクトリをルートディレクトリフィールドへ、段階１６２５で得られたオブジェクトＩＤをオブジェクトＩＤフィールドへ、エディションが存在するブランチＩＤをブランチフィールドへ入れる。
【００６７】
ステージエリアの世代ＩＤを取ることによって、モジュール１３１６は、ステージエリア「ｓ」を新たなエディションへ本質的に変換する。結果的に、エディションが生成された時に、エディション生成モジュール１３１６は段階１６４０において、新たな世代ＩＤを取得し、段階１６５０において、この世代ＩＤをステージエリアへ割り当てる。
【００６８】
図１７Ａ−Ｃは、ブランチ生成モジュール１３４６のオペレーションを示す。
ブランチを生成するために、モジュール１３４６は段階１７０５において、現在作成されつつあるブランチがメインブランチであるか否かを判定する。ブランチがメインブランチでない場合、モジュール１３４６は段階１７１０において、新たなブランチが派生した、「エディションｂ」と呼ばれる、親ブランチからのベースエディションの世代ＩＤを取得する。「エディションｂ」は親ブランチの上に追加された任意のものである。次にモジュール１３４６は段階１７１５において、「エディションｂ」の世代ＩＤから派生された新たな世代ＩＤを世代ＩＤモジュール１３４８から取得する。次に「エディションｅ」と呼ばれる初期エディションが、「エディションｂ」としての同じルートディレクトリと段階１７１５で得られた世代ＩＤとを使って段階１７２０において生成される。更に、ゼロ又はそれ以上のワークエリアが段階1７３０において作成され、各ワークエリアはエディションｅと同じルートディレクトリを有し、エディションｅの世代ＩＤから派生されたのとは異なる世代ＩＤを有している。ワークエリアは、ブランチ作成の時点又はそれよりも後の時点で作成される。エディションｅと同じルートディレクトリを有し且つエディションｅの世代ＩＤから派生された世代ＩＤを有するステージエリアが、段階1７４０において作成される。エディションｅ、ワークエリア、ステージエリアは、図１４-１６で述べられた方法に従って作成される。
【００６９】
段階１７０５を参照すると、作成中のブランチがメインブランチである場合、モジュール１３４６は段階1７５０において、ｇ０と呼ばれるルート世代ＩＤを取得する。ルート世代ＩＤは、固有の数を生成するための従来プログラムを使って生成される数であり、別の世代ＩＤから派生されるものではない。次にモジュール１３４６は段階１７５５において、ｄ０と呼ばれる空のディレクトリを生成し、段階１７６０において、ｈ０と呼ばれるディレクトリのための履歴オブジェクトを生成する。モジュール１３４６は段階１７６５において、履歴オブジェクトが世代ｇ０におけるディレクトリｄ０に関係することを示す履歴オブジェクトへのエントリを追加する。このエントリは表記法（ｇ０，ｄ０）で表される。
【００７０】
モジュール１３４６は、履歴オブジェクトを作成した後、段階１７７０において、ルートディレクトリｄ０とルート世代ｇ０とを有する初期エディションを生成する。又、モジュール１３４６は段階１７７５において、１つ又はそれ以上のワークエリアと、１つのステージエリアを作成するが、それぞれのエリアは初期エディション（即ち、空の）と同じルートディレクトリと、ルート世代から派生されたのとは異なる世代ＩＤとを有している。ワークエリアはブランチ生成の時に生成される必要はないこと、即ちそれより後に生成されてもよいことに注目されたい。
【００７１】
追加アイテムモジュール１３１８により、ファイルやディレクトリのようなオブジェクトをワークエリア又はステージエリアへ追加できる。図１８Ａ−Ｄは、コンテンツ「ｐ」を有するアイテム「ｎ」をエリア「ａ」のディレクトリ「ｄ」へ加えるための追加アイテムモジュール１３１８のオペレーションを示す。エリア「ａ」はワークエリアでもステージエリアでもよく、アイテム「ｎ」はファイルでもディレクトリでもよい。アイテム「ｆ」はファイルでもディレクトリでもよい。アイテムを加えるため、モジュール１３１８は段階１８０５において、「ｇ」と呼ばれるエリア「ａ」のための世代ＩＤを識別する。次にモジュール１３１８は段階１８１０において、ディレクトリ「ｄ」を読み出し、段階１８１５において、世代「ｇ」用の世代ページがあるか否かを判定する。ディレクトリ「ｄ」のための世代ページがない場合、モジュール１３１８は段階１８２０において、世代ページを有し最も緊密な関係にある親世代（「最適一致世代」）の世代ページをコピーすることにより、ディレクトリ「ｄ」のための世代ページを生成する。世代ページを生成又は作成するための世代ページを見つけ出した後に、モジュール１３１８は段階１８２５において、名前「ｎ」を有するアイテムに関する世代ページのコンテンツをスキャンし、段階１８３５において、アイテム「ｎ」が世代「ｇ」中のディレクトリ「ｄ」に存在するか否かを判定する。「ｎ」と名付けられたアイテムが世代「ｇ」のディレクトリ「ｄ」に見つからない場合、モジュール１３１８は段階１８４０において、コンテンツ「ｆ」が世代「ｇ」中のアイテム「ｎ」に関係していることを示すエントリを備えた履歴オブジェクトを履歴オブジェクト中に作成する。このようなエントリを表すために表記法（ｆ，ｇ）を使う。続いて、モジュール１３１８は段階１８４５において、表記法（ｎ，ｈ）で表されるエントリを、ファイル「ｎ」が履歴オブジェクト「ｈ」に関係していることを示す世代ページ「ｇ」へ加える。アイテム「ｎ」をディレクトリ「ｄ」へ加えるために、アイテム「ｎ」をディレクトリ「ｄ」へ仮想的にコピーすることも物理的にコピーすることもないことに注目されたい。ディレクトリ「ｄ」は単なる参照アイテム「ｎ」である。
【００７２】
アイテム「ｎ」がディレクトリへ既に加えられている場合、段階１８３５での質問への答はイエスとなるが、アイテム「ｎ」の更新されたバージョンが既存のバージョン（即ち、新コンテンツがアイテム「ｎ」と現在関係付けられつつある）に取って代わる。この場合、モジュール１３１８は段階１８５０において、ファイル「ｎ」が変更された最も新しい世代のファイル「ｎ」に関係する履歴オブジェクトのコンテンツをスキャンする。次にモジュール１３１８は段階１８５５において、アイテム「ｎ」が世代「ｇ」で変更されたか否かを判定する（即ちモジュール１３１８は、アイテム「ｎ」がエリア「ａ」において変更されたか否かを判定する。何故ならエリア「ａ」は世代ＩＤ「ｇ」を有しているからである）。アイテム「ｎ」が世代「ｇ」で変更されていない場合、次にモジュール１３１８は段階１８６０において、コンテンツ「ｆ」が世代「ｇ」のファイルに関係していることを示す履歴オブジェクトへエントリを追加する。アイテム「ｆ」は、アイテム「ｎ」の以前のコンテンツを示すフィールドを有する（即ちアイテム「ｆ」は、アイテム「ｎ」の以前のコンテンツへのポインタを含んでいる）。モジュール１３１８は段階１８６５において、最も良好に一致する世代中の「ｎ」のコンテンツを示すために、アイテム「ｆ」の以前のフィールドをセットする。
【００７３】
段階１８５５を参照すると、アイテム「ｎ」が世代「ｇ」で変更された場合、モジュール１３１８は段階１８７０において、世代「ｇ」においてアイテム「ｎ」のコンテンツがアイテム「ｆ」であることを反映するために、世代「ｇ」に関係する履歴アイテムエントリを変更する。次にモジュール１３１８は段階１８７５において、アイテム「ｆ」の以前のフィールドが世代「ｇ」の「ｎ」の以前のコンテンツを指すように設定する。
【００７４】
リソースを再請求するために、オブジェクトが如何なるエリアからもアクセスできない場合、当該オブジェクト（例：ディレクトリ、ファイル、履歴オブジェクト）は記憶装置から物理的に削除される。エリアへオブジェクトを加えたりエリアからオブジェクトを削除したりすることは、オブジェクトの物理的なコピーが１つだけしばしば記憶されるので、仮想的に行える。従って、オブジェクトの物理的なコピーを削除すべきか否かを判定するためには、何れかのエリアから当該オブジェクトへアクセスできるか否かを知ることが必要である。あるエリアからオブジェクトへアクセスできる場合、そのオブジェクトは当該エリアにおいて参照される。任意のエリアからあるオブジェクトへアクセスできるか否かを判定するには、各オブジェクトのための参照カウントが維持され、参照カウントはオブジェクトへアクセスすることのできるエリアの数を示すことになる。オブジェクトの参照カウントがゼロの場合、オブジェクトは削除することができる。
【００７５】
参照カウントを計算できるようにするため、各オブジェクトは「参照リスト」と「反参照リスト」へ関係付けられる。参照リストは、オブジェクトが加えられたディレクトリを示し、参照される各ディレクトリにつき、当該オブジェクトがディレクトリに加えられた際の世代（即ちエリア）を示す。厳密には、１つのオブジェクトがディレクトリに加えられる都度、１つのエントリが参照リストに加えられ、当該オブジェクトがディレクトリに加えられた際の世代が示される。
【００７６】
反参照リストは、オブジェクトが取り除かれたディレクトリを示し、参照される各ディレクトリにつき、当該オブジェクトが取り除かれた際の世代を示す。厳密には、１つのオブジェクトがディレクトリから取り出される都度、１つのエントリが反参照リストに加えられ、当該オブジェクトがディレクトリから取り除かれた際のディレクトリと世代を示すことになる。
【００７７】
追加直接参照モジュール１３２２は、エントリを参照リストに加える。図１９は、オブジェクト（例：ファイル又はディレクトリ又は履歴オブジェクト）がエリア「ａ」のあるディレクトリ「ｄ」に加えられる際の追加直接参照モジュール１３２２のオペレーションを示す。オブジェクト「ｃ」がディレクトリ「ｄ」に追加されるとき、「ｃ」に対するｄの直接参照が追加される。換言すると、「ｃ」の参照リストは、「ｃ」がディレクトリ「ｄ」に加えられたことを示す。直接参照を追加するために、追加直接参照モジュール１３２２はまず段階１９１０において、エリア「ａ」の世代を得るがこれを便宜上「ｇ」と呼ぶ。次に追加直接参照モジュール１３２２は段階１９２０において、オブジェクト「ｃ」の参照リストに、オブジェクト「ｃ」が世代「ｇ」でディレクトリ「ｄ」へ加えられたことを示すエントリがあるか否かを判定する。便宜上このエントリを表記法（ｇ，ｄ）で表す。（ｇ，ｄ）がオブジェクト「ｃ」の参照リストになければ、段階１９３０において当該エントリが参照リストに加えられる。
【００７８】
（ｇ，ｄ）が参照リストに加えられた後、又は（ｇ，ｄ）が既に参照リストにある場合、追加直接参照モジュール１３２２は段階１９４０において、エントリ（ｇ，ｄ）が反参照リストにあるか否かを判定する。オブジェクト「ｃ」が以前に世代「ｇ」でディレクトリ「ｐ」から取り出されていたなら、エントリ（ｇ，ｄ）は反参照リストにあることになる。エントリ（ｇ，ｄ）がオブジェクト「ｃ」の反参照リストになければ、直接参照を加える処理は完了である。エントリ（ｇ，ｄ）が反参照リストにあれば、当該エントリは段階１９５０において、反参照リストから外される。更には、世代「ｇ」から直接派生した世代、それをｇiと呼ぶことにするがその各世代について、エントリ（ｇi，ｄ）が段階１９６０において、反参照リストに加えられる。この最後の段階を行うのは、派生した世代はその親世代と同じコンテンツから始まっているからである。従って、オブジェクトが１つの世代でアクセスされ得るなら、子世代の派生後に当オブジェクトが親ディレクトリに加えられていない限り、又はオブジェクトが子世代から特定して取り出されてない限り、オブジェクトはその世代から派生した全子世代からアクセスすることができる。必然的に、あるオブジェクトが既存の子世代を有するある世代においてあるディレクトリに追加される場合、オブジェクトは既存の子世代が派生した時点では親世代の部分ではなかったので、反参照リストは、当該オブジェクトが既存の子世代からアクセスされようがないことを示すはずである。無論、オブジェクトは、図１８Ａ−Ｄに関連して図示され説明された方法を使って、子世代に加えることもできる。
【００７９】
取り除き直接参照モジュール１３２４は、エントリを反参照リストに加える。
図２０は、オブジェクト「ｃ」がエリア「ａ」のディレクトリ「ｄ」から取り除かれる場合の取り除き直接参照モジュール１３２４のオペレーションを示す。取り除き直接参照モジュール１３２４は段階２０１０において、便宜上「ｇ」と呼ぶ、エリアａの世代ＩＤを確認する。次に取り除き直接参照モジュール１３２４は段階２０２０において、以前にオブジェクト「ｃ」が世代「ｇ」でディレクトリ「ｄ」へ加えられたことを示すオブジェクトの参照リストにエントリがあるか否かを判定する。このようなエントリを表記法（ｇ，ｄ）で表す。（ｇ，ｄ）が参照リストになければ、オブジェクト「ｃ」は世代「ｇ」でのディレクトリ「ｄ」に対する参照リストを有したことがなかったということで、処理は完了する。
従って、どの参照リストも取り除かれる必要はない。
【００８０】
（ｇ，ｄ）が参照リストにあれば、（ｇ，ｄ）は段階２０３０において、オブジェクト「ｃ」の参照リストから取り除かれる。更に、世代「ｇ」から派生した世代、それを「ｇi」と呼ぶことにするがその各世代につき、エントリ（ｇi，ｄ）が反参照リストになければ、当該エントリは段階２０４０において、参照リストに加えられる。この段階を行うのは、オブジェクト「ｃ」が既存の子世代からアクセス可能であったなら、オブジェクト「ｃ」が親世代から取り除かれているという事実に関わらず、オブジェクト「ｃ」へは既存の子世代からアクセスできるということを参照リストが示すからである。
【００８１】
段階２０４０の後、取り除き直接参照モジュール１３２４は段階２０５０において、エントリ（ｇ、ｄ）が反参照リストにあるか否かを判定する。当該エントリがまだ反参照リストになければ、当該エントリが段階２０６０において、反参照リストに加えられる。そうでなければ、直接参照を取り除く処理は完了する。
エントリ（ｇ，ｄ）が反参照リストに既にあるはずがないとしても、エントリがより早い時期に反参照リストへ間違って加えられた場合に備えて、取り除き直接参照モジュール１３２４は、この判定を行う。
【００８２】
参照カウントモジュール１３２０は、あるアイテムに対する参照の数を計算する。計算のため、参照カウントモジュール１３２０は、２個組のリストを維持するが、これは初期には空である。参照カウントモジュール１３２０は、アイテム「ｆ」に対して行われた参照の数を表すために、整数ｎも使用するが、これは最初ゼロである。
【００８３】
図２１Ａ−Ｂは、あるアイテム「ｆ」の参照カウントを計算するための参照カウントモジュール１３２０のオペレーションを示す。参照カウントモジュール１３２０は段階２１１０及び段階２１２０において、アイテム「ｆ」の参照リスト及び反参照リストを検索する。参照カウントモジュールは段階２５２５で、便宜上「ｇ」と呼ぶ、系図ツリー（本発明の全エリアは系図に編成できるということを思い出されたい）のルートノードの世代ＩＤを得る。参照カウントモジュール１３２０は段階２１３０において、世代「ｇ」を有する参照リスト中の全エントリを見つける。例えば、アイテム「ｆ」が世代「ｇ」においてディレクトリｄ1へ加えられた場合、参照リストにはエントリ（ｇ，ｄ1）があるはずで、参照カウントモジュール１３２０はこのエントリを突き止めるであろう。世代「ｇ」を持つエントリについて、参照カウントモジュール１３２０は段階２１３０において、エントリ（アイテム名，＋）をリスト「ｐ」に加えるが、この場合の「アイテム名」は世代「ｇ」において参照されたアイテムの名前である。「＋」はアイテムが（反参照リストとは反対の）参照リスト中に参照されたことを意味する。
【００８４】
例えば、エントリ（ｇ，ｄ１）がアイテム「ｆ」の参照リスト中に発見されたなら、エントリ（ｄ１，＋）がリスト「ｐ」に加えられる。リスト「ｐ」が同じアイテム名を持つエントリ（例：ｄ１，−）を既に含んでいる場合、参照カウントモジュールはそのエントリが（アイテム名，＋）へ設定されるのを保証する。
【００８５】
参照カウントモジュール１３２０は段階２１４０において、世代「ｇ」を備えた反参照リスト中の全エントリを見つけるために、反参照リストの探索もする。世代「ｇ」の反参照リスト中の各エントリにつき、参照カウントモジュール１３２０は段階２１４０において、エントリ（アイテム名，−）をリスト「ｐ」へ加えるが、この場合の「−」はアイテムが反参照リスト中で参照されたことを意味する。リスト「ｐ」が同じアイテム名を持つエントリを既に含んでいる場合、参照カウントモジュールはそのエントリが（アイテム名，−）へ設定されるのを保証する。
【００８６】
次に参照カウントモジュール１３２０は段階２０５０において、「＋」を持つリスト「ｐ」中の各エントリにつき、ｎ＝ｎ＋１を設定する。ｎは初期にはゼロに設定されていることを思い出していただきたい。次に参照カウントモジュール１３２０は段階２１６０において、世代「ｇ」が子世代（即ち、世代「ｇ」から派生した世代）を有しているか否かを判定する。そうでない場合には、参照カウントは段階２１７０において完了し、ｎはアイテム「ｆ」への参照の数となる。世代「ｇ」が子世代を有する場合、各子世代につき、参照カウントモジュール１３２０は段階２１８０において、「ｇ」を子世代の世代ＩＤに等しく設定し、段階２１３０へ戻る。
【００８７】
図２２は、エリア「ａ」のディレクトリ「ｄ」のコンテンツを読み出すための読み出しディレクトリモジュール１３２６のオペレーションを示す。読み出しディレクトリモジュール１３２６は段階２２１０において、エリアａの世代を得るが、これを「ｇ」と称する。読み出しディレクトリモジュール１３２６は、ディレクトリ全体を構文解析し、世代「ｇ」のための世代ページがあるか否かを段階２２２０において判定する。ディレクトリ「ｄ」が既にエリアａで変更されていたなら、世代「ｇ」のための世代ページがあることになる。世代「ｇ」のための世代ページがあるなら、読み出しディレクトリモジュール１３２６は段階２２３０において、世代ページ「ｇ」上のエントリのリストを返却する。そうでないならば、ディレクトリは段階２２４０において、最も関係の深い親世代ページの世代ページ（最適一致世代ページ）上のエントリのリストを返却する。
【００８８】
読み出しディレクトリモジュールのオペレーションの例を図１２に示した例を使って説明する。世代Ｇ３を有するエリア中のディレクトリのコンテンツを読み出すに当たり、読み出しディレクトリモジュール１３２６は、世代ページＧ３上の（複数）エントリのリストを戻すが、本例ではこれはエントリ（ｍ、ｈ０）である。
【００８９】
図面１２の世代が図１０に示す方法で関連付けられていると仮定する。世代Ｇ４中のディレクトリ「ｄ」のコンテンツを読み出すために、読み出しディレクトリモジュール１３２６は、Ｇ４用の世代ページがあるか否かを判定する。Ｇ４用の世代ページがないことから、読み出しディレクトリモジュール１３２６は最適一致世代ページにつき探索する。Ｇ１はＧ４に最も近密な親世代であるが、Ｇ１に当たる世代ページはない。Ｇ０が次に近密な親世代であり、Ｇ０に当たる世代ページはあるので、Ｇ０世代ページ中のエントリのリストが、Ｇ４のディレクトリのコンテンツとして返却される。
【００９０】
図２３Ａ−Ｂは、世代ＩＤ「ｇ」を有するエリア「ａ」中のディレクトリ「ｄ」からアイテム「ｎ」が取り除かれる場合の、取り除きアイテムモジュール１３２８のオペレーションを示す。アイテムｎは、ファイル又は別のディレクトリのようなディレクトリ中の何れのオブジェクトでもよい。アイテムをディレクトリ「ｄ」から取り除くために、ディレクトリ「ｄ」は段階２３１０において、図２２に関連して説明した方法に従って読み出される。取り除きアイテムモジュール１３２８は段階２３２０において、世代「ｇ」用の世代ページがディレクトリ「ｄ」にあるか否かを判定する。ない場合には、最も近密な親世代（最適一致世代）から世代ページをコピーすることにより、段階２３３０おいて世代「ｇ」用の世代ページが作成される。
【００９１】
取り除きアイテムモジュール１３２８は段階２３３０において、世代ページ「ｇ」中にアイテムｎに当たるエントリがあるか否かを判定する。ない場合、取り除きアイテムモジュール１３２８は段階２３３０において、アイテムｎが世代「ｇ」のディレクトリ「ｄ」にないので従って世代「ｇ」でディレクトリから取り除くことが不可能であるという理由で、エラーが起きたことを示す。
【００９２】
段階２３３０に戻ると、世代ページｇにアイテムｎに当たるエントリがあるなら、取り除きアイテムモジュール１３２８は段階２３５０において、ｎに対応する履歴オブジェクトを取得する。取り除きアイテムモジュール１３２８は段階２３５５において、アイテムｎが世代「ｇ」中に変更されたことを履歴オブジェクトが示しているか否かを判定する。換言すると、取り除きアイテムモジュール１３２８は、履歴オブジェクトが、世代が「ｇ」のエントリを含んでいるか否かを判定する。
【００９３】
アイテムｎが世代「ｇ」で変わっていなければ、取り除きアイテムモジュール１３２８は段階２３７０において、アイテムｎが世代「ｇ」でディレクトリ「ｄ」から取り除かれたことを示すエントリを履歴オブジェクトへ加える。アイテムｎは本処理では仮想的に削除されるので、このエントリを追加することにより、アイテムｎをディレクトリ「ｄ」から世代「ｇ」で有効に削除することになる。
【００９４】
このエントリは表記法（ｇ，ｚ）により表され、この場合「ｚ」はアイテムが取り除かれてしまったことを示すオブジェクトを表す。ｚオブジェクトがアイテムｎのために作成されてなかったならば、取り除きアイテムモジュール１３２８はｚオブジェクトを作成する。
【００９５】
段階２３５５に関して、アイテムｎが世代「ｇ」で変更されていたなら、取り除きアイテムモジュール１３２８は段階２３６０において、ｎがディレクトリ「ｄ」から世代「ｇ」で取り除かれたことを示すために、世代「ｇ」に対応する履歴オブジェクト中のエントリを変更する（即ち、エントリは（ｇ，ｚ）となる）。取り除きアイテムモジュール１３２８は、まだオブジェクトが存在していなければ、アイテムｎのための「ｚ」を作成する。
【００９６】
図１２に示されたファイルコンテンツ１２３５のように、ｚオブジェクトはあるアイテムの以前のコンテンツを示すフィールドも有している。このフィールドは「以前のフィールド」と称される。段階２３６０又は段階２３７０の後で、ｚオブジェクトの以前のフィールドは段階２３８０において、以前のコンテンツｎを指すように世代「ｇ」において設定される。
【００９７】
図２４Ａ−Ｂは、世代ＩＤ「ｇ」を有するワークエリア「ａ」のディレクトリ「ｄ」中にファイル「ｎ」を編集するための編集ファイルモジュール１３２０のオペレーションを示す。編集ファイルモジュール１３２０は段階２４０５において、ファイル「ｎ」に対する書き込みコマンドを受信する。編集ファイルモジュール１３２０は段階２４１０において、次にファイルｎについての履歴オブジェクトを取得し、ファイルｎが世代「ｇ」で変更されたか否か（即ち、世代が「ｇ」のエントリがあるか否か）を段階２４２０において判定する。そうであるなら、編集ファイルモジュール１３２０は段階２４３０において、世代「ｇ」でファイルｎに関係付けられたコンテンツへファイル「ｎ」に対する変更を全て書き込む。
【００９８】
履歴オブジェクトが世代「ｇ」のエントリを持たない場合、編集ファイルモジュール１３２０は段階２４４０において、最適一致世代を有するエントリを見つける。編集ファイルモジュール１３２０は次に段階２４５０において、ｆ１と呼ばれる、段階２４４０でエントリに関係付けられたファイルをコピーし、ファイルｆ１の新コピーに全変更を段階２４６０において書き込むが、この書き込まれたファイルをｆ２と呼ぶ。世代「ｇ」においてファイルｎのコンテンツがファイルｆ２のコンテンツであることを示すエントリが段階２４７０において、履歴オブジェクトに加えられる。換言すれば、編集ファイルモジュール１３２０は表記法（ｇ、ｆ２）により表されるエントリを履歴オブジェクトへ加えるのである。
【００９９】
図２５は、ファイル又はディレクトリである、エリアａのディレクトリｄ１中のアイテムｎ１を、エリアａのディレクトリｄ２中のアイテムｎ２に再命名するための再命名モジュール１３３２のオペレーションを示す。再命名モジュール１３３２は段階２５１０において、ディレクトリｄ１のアイテムｎ１の履歴オブジェクトを取得するが、この履歴オブジェクトはｈ１と呼ばれる。このような履歴オブジェクトが存在しない場合は、再命名モジュール１３３２はユーザにエラーが発生したと報告する点に留意されたい。履歴オブジェクトを取得後、再命名オブジェクト１３３２は段階２５２０において、名前ｎ２を有するアイテムがディレクトリｄ２に存在するか否か判定する。存在するならば、再命名モジュールは段階２５２３において、アイテムｎ２に対する上書き防止があるか否かを判定する。１実施形態では、ディレクトリに対する上書き防止はあるがファイルに対してはない。上書き防止が存在する場合、再命名モジュール１３３２は段階２５２７において、アイテムｎ２がディレクトリｄ２に既に存在することを報告する。上書き防止がない場合、再命名モジュール１３３２は段階２８３０において、既存のアイテムｎ２を図２３Ａ−ｄに関連して図示及び説明した方法に則りディレクトリｄ２から取り除く。
【０１００】
既存のアイテムｎ２がディレクトリｄ２から一旦取り除かれてしまった場合、又はアイテムｎ２がディレクトリｄ２には存在しなかった場合、再命名モジュール１３３２は段階２５４０において、名前ｎ２を持つ新アイテムをディレクトリｄ２に加える。再命名モジュール１３３２は、履歴オブジェクトｈ１をディレクトリｄ２のアイテムｎ２に関係付ける。アイテムｎ２のコンテンツの「以前のフィールド」において、再命名モジュール１３３２は、ｎ１がｎ２という「先祖からの再命名」（以下に定義する）であることを示す。再命名処理は、ｄ１＝ｄ２なら同じであることに留意されたい。
【０１０１】
図２６Ａ−Ｂは、エリアａのディレクトリ「ｄ」につきフルネーム経路を生成するための生成ディレクトリ経路モジュール１３３４のオペレーションを示す。
生成ディレクトリ経路モジュール１３３４は、エリアａのディレクトリ「ｄ」を読み出し、ディレクトリ「ｄ」に対する親ディレクトリを識別するが、これをＰ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が同じコンテンツを指しているか（即ち、ｆtargetとｆreferenceが同じか）否かを確かめる。それらが同じコンテンツを指している場合は、コンフリクト（矛盾）照合モジュール１３３８はコンフリクト（矛盾）がないことを発見する。２個のファイルが同じコンテンツを有してない場合は、コンフリクト（矛盾）照合モジュール１３３８は段階２９４０において、ｆreferenceがｆtargetの先祖（即ち、以下に定義するように、同一名の先祖、先祖からのコピー、又は先祖からの再命名）であるか否かを判定する。ｆreferenceが先祖であるなら、ｆtargetはｆreferenceの望ましい修正である可能性が高いので、コンフリクト（矛盾）はない。そうでないなら、コンフリクト（矛盾）が存在する。
【０１１２】
図３０Ａ−Ｂは、エリアａtargetのディレクトリｄtargetを、エリアａreferenceのディレクトリｄreferenceと比較するための比較ディレクトリモジュール１３４０のオペレーションを示す。比較するために、比較ディレクトリモジュール１３４０は段階３００５において、図２２に関連して図示及び説明した方法に則り、エリアａtargetのディレクトリｄtargetのコンテンツを読み出す。コンフリクト（矛盾）照合モジュールも段階３０１０において、図２２に関連して図示及び説明された方法に則り、エリアａreferenceのディレクトリｄreferenceのコンテンツを読み出す。
【０１１３】
比較ディレクトリモジュール１３４０は段階３０１５において、ディレクトリｄtargetの最初のアイテムを識別し、ディレクトリｄtargetの最初のアイテムと同じ名前のアイテムがディレクトリｄreference中にあるか否かを段階３０２０において判定する。ない場合には、比較ディレクトリモジュール１３４０は、ｄtarget中に識別されるアイテムに一致するアイテムがｄreferenceにはないことを段階３０４５において報告し、段階３０５０に進む。そうでない場合には、比較ディレクトリモジュール１３４０は段階３０２５において、同一名を有する２個のアイテムが同じコンテンツを有するか否かを判定する。このような比較は、各アイテムの履歴オブジェクトを参照することにより行なわれ、エリアａreferenceのディレクトリｄreferenceの履歴オブジェクトが、エリアａtargetのディレクトリｄtargetの履歴オブジェクトと同じコンテンツを指しているなら、双方のディレクトリのコンテンツは同じである。コンテンツが同じであるなら、比較ディレクトリモジュール１３４０は段階３０３０において、アイテムが同じ名前とコンテンツを有することを報告し、比較ディレクトリモジュール１３４０は段階３０５０に進む。双方のコンテンツが同じでないなら、比較ディレクトリモジュール１３４０は段階３０３５において、名前は同じであるがコンテンツは違うことを報告し、比較ディレクトリモジュール１３４０は段階３０５０へ進む。
【０１１４】
段階３０５０では、比較ディレクトリモジュール１３４０は段階３０５０において、ｄtarget中に別のアイテムがあるか否かを確かめる。ｄtarget中に別のアイテムがあれば、比較ディレクトリモジュール１３４０は段階３０５３において、次のアイテムを識別し、段階３０２０へ戻る。ｄtarget中に別のアイテムがなければ、比較ディレクトリモジュール１３４０は段階３０５５において、ｄreference中の最初のアイテムを識別する。比較ディレクトリモジュール１３４０は段階３０６０において、識別されたアイテムがｄ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とＦreferenceの両方の先祖であるファイルがあるか否かを判定する。共通ファイルがある場合には、比較ファイルモジュール１３４１は段階３１７０において、ＦreferenceとＦ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.html"に付け加えられる。
【０１４０】
エリア接頭語は、文書ルート接頭語の前、又は適用可能な場合は文書ルート接頭語に代わる特別接頭語の前に付け加えられる。エリア接頭語は、元のリクエストと共に送信された「クッキー」をデコードすることにより派生される。クッキーはウェブブラウザにより記憶されている永続的な少量のデータであって、バーチャライゼーションモジュール１３７へ送信される。クッキーは様々なタイプの情報（ユーザのアイデンティティ、ユーザセッションのアイデンティティ（「セッションＩＤ」）、ポート番号など）を含むことができるが、そのような情報の１つにビューイング域の経路の標示がある。１実施形態では、クッキーは実際のエリア接頭語を含んでいる。別の実施形態では、バーチャライゼーションモジュールは、セッションＩＤ又はポート番号のような別タイプの情報をクッキーから抽出し、抽出された情報の型をエリア接頭語へマップする外部ルックアップ表中のエリア接頭語をルックアップする。
【０１４１】
文書ルート接頭語例を継続するため、元のリクエストと共に送られたクッキーから派生したエリア接頭語が“/iw-mount/default/main/workarea/joe"であるなら、変換されたリクエストは以下の通りになろう。
「GET/iw-mount/default/main/workarea/joe/directoryA/directoryB/ documents/index.html.」
【０１４２】
ウェブブラウザが全ＨＴＴＰリクエストをバーチャライゼーションモジュール１３７に経路付けするか、又はその内の幾つかだけを経路付けするかは、システム中のＨＴＭＬ文書内に保有されているリンクのタイプに左右される。ＨＴＭＬ文書内に保有されているリンクには少なくとも３つのタイプ、即ち相対リンク、絶対リンク、及び完全修飾リンクがある。完全修飾リンクは、明示プロトコル仕様と明示ホスト名とを含むリンクで、明示ホスト名の後には文書への完全経路名が続く。絶対リンクは、プロトコル仕様もホスト名も持たないが、文書への完全経路名を含むリンクである。絶対リンクは通常、初期スラッシュ記号（“／”）で始まる。相対リンクは、絶対リンクに似ているが、代わりに先頭スラッシュ記号（“／”）により特徴付けられ、これは経路が現在の文書リンクに関係することを示す。換言すると、相対リンクは、要求された文書の実際の名前以外は、現在の文書の同一完全経路名を有する。
【０１４３】
バーチャライゼーションモジュール１３７は、３つのタイプのリンク全てを処理できる。システム１００内に記憶されたＨＴＭＬコンテンツが完全修飾リンクのバーチャライゼーションを要求する場合、ウェブブラウザは全リクエストをバーチャライゼーションモジュール１３７に送信するように構成される。多くの共通ウェブブラウザは構成設定を使ってこの特性をサポートする。１実施形態によれば、ウェブサイトが完全修飾リンクの管理を必要としない場合、ウェブブラウザは絶対及び相対ＨＴＭＬリンクだけをバーチャライゼーションモジュール１３７に送る。ウェブサーバは通常、絶対及び相対リンクがバーチャライゼーションモジュール１３７に自動的に送られるようにするのに特別な構成を全く必要としない。
【０１４４】
図３６Ａ−Ｂは、絶対及び相対リクエストを取り扱うためのバーチャライゼーションモジュール１３７のオペレーションを示す。バーチャライゼーションモジュール１３７は段階３６１０において、開発ワークステーションの１つにあるウェブブラウザからＨＴＴＰリクエストを受信し、段階３６２０において当該リクエストからユニフォームリソースロケータ（ＵＲＬ）アドレスを抽出する。バーチャライゼーションモジュール１３７は段階３６３０において、ＵＲＬアドレスと共に送信されているクッキーも抽出する。
【０１４５】
バーチャライゼーションモジュール１３７は段階３６４０において、リクエストが絶対リクエストか相対リクエストなのかを判定する。あるリクエスト実施形態で、これらのリクエストは、相対ＨＴＭＬリクエストなら、バーチャライゼーションモジュール１３７により処理される（これはウェブブラウザにより自動的に行なわれる）以前にエリア接頭語が既にリクエストに付け加えられている事実により、絶対リクエストなら、バーチャライゼーションモジュール１３７により処理される以前にエリア接頭語が付け加えられていないという事実により、区別される。リクエストが相対リクエストの場合、当該リクエストは正しいファイルシステムとディレクトリ（即ち、ビューイング文書へアクセスするためファイルシステムとディレクトリ）へ方向決めされており、バーチャライゼーションモジュール１３７は段階３６９０においてリクエストをウェブサーバに送る。
【０１４６】
リクエストが絶対リクエストである場合、バーチャライゼーションモジュール１３７は段階３６５０において、ビューイング域が沿って存在するブランチに対応しているマッピング規則を探索し、段階３６６０において適切な接頭語（（先に説明したように）マッピング規則に基づく文書ルート接頭語又は特別接頭語の何れか）を選択する。バーチャライゼーションモジュール１３７は段階３６７０において、選択された接頭語を元のリクエスト又はその一部へ適切なマッピング規則に則り付け加える。
【０１４７】
バーチャライゼーションモジュール１３７は段階３６８０において、エリア接頭語をクッキーから（上述のように）抽出又は派生し、それを付け加えられた接頭語の前へ段階３６７０において付ける。リクエストの経路又はその一部はここで完成するので、モジュール１３７は修正されたリクエストをウェブサーバ１４５へ経路決めする。
【０１４８】
図３７は完全修飾リンクを処理するためのバーチャライゼーションモジュール１３７の方法を示す。バーチャライゼーションモジュール１３７は段階３７１０において、ＨＴＴＰリクエストを開発ワークステーション１１０の１つにあるウェブブラウザ１１０から受信し、段階３７２０においてＵＲＬとクッキーを当該リクエストから抽出する。
【０１４９】
次にバーチャライゼーションモジュール１３７は段階３７３０において、マッピング規則を介して完全修飾リクエストを探索し、当該リクエストがマッピング規則の正規表現と一致するかどうかを判定する。一致しない場合、リクエストは段階３７８０においてしかるべくウェブサーバに転送される。一致する場合、バーチャライゼーションモジュール１３７は段階３７５０において、マッピング規則に従って得た接頭語を当該リクエスト又はその一部へマッピング規則に則り付け加える。
【０１５０】
バーチャライゼーションモジュール１３７は段階３７６０において、エリア接頭語をクッキーから（上述のように）抽出又は派生させ、それをステップ３７５０で付け加えられた接頭語の前へ段階３７７０において付け加える。リクエストの経路はここで完成するので、モジュール１３７は変更されたリクエストをウェブサーバ１４５へ段階３７８０において経路決めする。
【０１５１】
バーチャライゼーションモジュール１３７により、外部ウェブサーバからのコンテンツを動的にスプライシングできる。場合によっては、ウェブサイトはシステム１００により管理されないコンテンツを含んでいる。これらの場合、バーチャライゼーションモジュール１３７は、文書が最初に探索された場所（例：ビューイング域）にないなら、文書リクエストを外部ウェブサーバへ動的に再方向付けすることができる。文書リクエストが、「４０４ファイルは発見されず」というＨＴＴＰエラーコードと共に戻された場合、バーチャライゼーションモジュール１３７はマッピング規則を探索し、そして一致するものが見つかったら、マッピング規則に則ってそのリクエストを変更する。変更されたリクエストは次に特定の外部宛先ウェブサーバに送信される。
【０１５２】
バーチャライゼーションモジュール１３７は、異なるブランチからのコンテンツも動的にスプライシングできる。ウェブサイトコンテンツは、異なる開発ブランチへ分離される場合もある。このような例では、バーチャライゼーションモジュール１３７が「４０４ファイルは発見されず」というＨＴＴＰエラーコードを受信するなら、バーチャライゼーションモジュール１３７は、既存の文書ルート接頭語を別のブランチの文書ルート接頭語に置き換える。変更されたリクエストはここでウェブサーバ１４５に送信される。
【０１５３】
図３８は、動的サイトベース又はブランチベースのスプライシングを実行するためのバーチャライゼーションモジュールのオペレーションを示す。バーチャライゼーションモジュール１３７は、ウェブサーバ１４５からＨＴＴＰリクエストの結果を受信する。バーチャライゼーションモジュールは、その結果から、要求された文書が見つかったかどうかを確定する。見つかった場合、バーチャライゼーションモジュール１３７は段階３８２５において、要求された文書を、バーチャライゼーションモジュールへリクエストを送った元のウェブブラウザへ転送する。文書が発見されない場合は、バーチャライゼーションモジュール１３７は段階３８３０において、マッピング規則を探索し、ウェブサーバへ送られたＨＴＴＰリクエスト又はその一部が何れかの規則の左側と一致するかどうかを段階３８４０において判定する。一致するなら、リクエストは段階３８５０においてマッピング規則に従って変更され、段階３８６０において適切なウェブサーバに転送される。
【０１５４】
当業者には理解されるように、本発明は、その精神並びに本質的特性から逸脱することなく他の具体的な形態に実施することができる。ウェブサイト開発は本明細書に開示された発明の多くの実用的なアプリケーションの１つにすぎない。
本明細書に開示された発明の別のアプリケーションには、ソースコード、メディアファイル（例：ＣＤ−ＲＯＭマルチメディア）、メディアエンジン等を開発することも含まれる。従って、本発明の開示は、冒頭の請求の範囲に述べられる本発明の範囲を制限することではなく例示することを意図するものである。
【図面の簡単な説明】
【０１５５】
【図１】本発明の１実施形態による、ウェブサイト開発用のコンピュータネットワークを示す図である。
【図２】本発明の１実施形態による、ウェブサイトコンテンツを開発するための（開発者の視点から見た）開発フローを示す。
【図３】本発明の１実施形態によるブランチの例を示す図である。
【図４】本発明の１実施形態による、メインブランチの初期コンテンツの例を示す図である。
【図５】本発明の１実施形態による、メインブランチの例を示す図である。
【図６】本発明の１実施形態による、メインブランチの別の例を示す図である。
【図７】本発明の１実施形態による、メインブランチとサブブランチの例を示す図である。
【図８】本発明の１実施形態による、エリアのディレクトリツリーの例を示す図である。
【図９】本発明の１実施形態による、ワークエリアオブジェクトの図的表示である。
【図１０】本発明の１実施形態による、世代ＩＤを派生するための方法を示す図である。
【図１１】本発明の１実施形態による、系図ツリーの例を示す図である。
【図１２】本発明の１実施形態による、ディレクトリの図的表示である。
【図１３】本発明の１実施形態によるウェブサイト開発モジュールを示す図である。
【図１４】本発明の１実施形態による、ワークエリア作成モジュールのオペレーションを示す図である。
【図１５】本発明の１実施形態による、ステージエリア作成モジュールのオペレーションを示す図である。
【図１６Ａ】本発明の１実施形態による、エディション作成モジュールのオペレーションを示す図である。
【図１６Ｂ】本発明の１実施形態による、エディション作成モジュールのオペレーションを示す図である。
【図１７Ａ】本発明の１実施形態によるブランチ作成モジュールのオペレーションを示す図である。
【図１７Ｂ】本発明の１実施形態によるブランチ作成モジュールのオペレーションを示す図である。
【図１７Ｃ】本発明の１実施形態によるブランチ作成モジュールのオペレーションを示す図である。
【図１８Ａ】本発明の１実施形態による追加アイテムモジュールのオペレーションを示す図である。
【図１８Ｂ】本発明の１実施形態による追加アイテムモジュールのオペレーションを示す図である。
【図１８Ｃ】本発明の１実施形態による追加アイテムモジュールのオペレーションを示す図である。
【図１８Ｄ】本発明の１実施形態による追加アイテムモジュールのオペレーションを示す図である。
【図１９】本発明の１実施形態による、追加直接リファレンスモジュールのオペレーションを示す図である。
【図２０】本発明の１実施形態による、取り除き直接リファレンスモジュールのオペレーションを示す図である。
【図２１Ａ】本発明の１実施形態による参照カウントモジュールのオペレーションを示す図である。
【図２１Ｂ】本発明の１実施形態による参照カウントモジュールのオペレーションを示す図である。
【図２２】本発明の１実施形態による、読み出しディレクトリモジュールのオペレーションを示す図である。
【図２３Ａ】本発明の１実施形態による、取り除きアイテムモジュールのオペレーションを示す図である。
【図２３Ｂ】本発明の１実施形態による、取り除きアイテムモジュールのオペレーションを示す図である。
【図２４Ａ】本発明の１実施形態による、エディットファイルモジュールのオペレーションを示す図である。
【図２４Ｂ】本発明の１実施形態による、エディットファイルモジュールのオペレーションを示す図である。
【図２５】本発明の１実施形態による、再命名モジュールのオペレーションを示す図である。
【図２６Ａ】本発明の１実施形態による、生成ディレクトリ経路モジュールのオペレーションを示す図である。
【図２６Ｂ】本発明の１実施形態による、生成ディレクトリ経路モジュールのオペレーションを示す図である。
【図２７】本発明の１実施形態による、生成ベースネームモジュールのオペレーションを示す図である。
【図２８Ａ】本発明の１実施形態による、提出モジュールのオペレーションを示す図である。
【図２８Ｂ】本発明の１実施形態による、提出モジュールのオペレーションを示す図である。
【図２８Ｃ】本発明の１実施形態による、提出モジュールのオペレーションを示す図である。
【図２９】本発明の１実施形態による、コンフリクト（矛盾）照合モジュールのオペレーションを示す図である。
【図３０Ａ】本発明の１実施形態による、比較ディレクトリモジュールのオペレーションを示す図である。
【図３０Ｂ】本発明の１実施形態による、比較ディレクトリモジュールのオペレーションを示す図である。
【図３１Ａ】本発明の１実施形態による比較ファイルモジュールのオペレーションを示す図である。
【図３１Ｂ】本発明の１実施形態による比較ファイルモジュールのオペレーションを示す図である。
【図３２】本発明の１実施形態による、エリア削除モジュールのオペレーションを示す図である。
【図３３Ａ】本発明の１実施形態による、ロックモジュールのオペレーションを示す図である。
【図３３Ｂ】本発明の１実施形態による、ロックモジュールのオペレーションを示す図である。
【図３４】本発明の１実施形態による、ロックモジュールの別のオペレーションを示す図である。
【図３５】本発明の１実施形態による、ウェブブラウザと、ＨＴＴＰプロトコルバーチャライゼーションモジュールと、ウェブサーバとの間のコミュニケーションパスを示す図である。
【図３６Ａ】本発明の１実施形態による、ＨＴＴＰプロトコルバーチャライゼーションモジュールのオペレーションを示す図である。
【図３６Ｂ】本発明の１実施形態による、ＨＴＴＰプロトコルバーチャライゼーションモジュールのオペレーションを示す図である。
【図３７】本発明の１実施形態による、ＨＴＴＰプロトコルバーチャライゼーションモジュールの別のオペレーションを示す図である。
【図３８】本発明の１実施形態による、ＨＴＴＰプロトコルバーチャライゼーションモジュールの更に別のオペレーションを示す図である。
【符号の説明】
【０１５６】
１００  ウェブサイト開発用のコンピュータネットワーク
１１０  開発ワークステーション
１２０  コンピュータネットワーク
１３０  開発サーバ１３０
１５０  メモリ
１６０  支援記憶装置
１７０  プロダクションウェブサーバ
３００  単一のブランチ
３１０  ワークエリア
３２０  ステージエリア
３３０  ウェブサイトエディション
４００  メインブランチ
４１０  空のワークエリア
４２０  空のステージエリア
４３０  空のエディション
【図１】
2009009590.tif 000003
【図２】
2009009590.tif 000004
【図３】
2009009590.tif 000005
【図４】
2009009590.tif 000006
【図５】
2009009590.tif 000007
【図６】
2009009590.tif 000008
【図７】
2009009590.tif 000009
【図８】
2009009590.tif 000010
【図９】
2009009590.tif 000011
【図１０】
2009009590.tif 000012
【図１１】
2009009590.tif 000013
【図１２】
2009009590.tif 000014
【図１３】
2009009590.tif 000015
【図１４】
2009009590.tif 000016
【図１５】
2009009590.tif 000017
【図１６Ａ】
2009009590.tif 000018
【図１６Ｂ】
2009009590.tif 000019
【図１７Ａ】
2009009590.tif 000020
【図１７Ｂ】
2009009590.tif 000021
【図１７Ｃ】
2009009590.tif 000022
【図１８Ａ】
2009009590.tif 000023
【図１８Ｂ】
2009009590.tif 000024
【図１８Ｃ】
2009009590.tif 000025
【図１８Ｄ】
2009009590.tif 000026
【図１９】
2009009590.tif 000027
【図２０】
2009009590.tif 000028
【図２１Ａ】
2009009590.tif 000029
【図２１Ｂ】
2009009590.tif 000030
【図２２】
2009009590.tif 000031
【図２３Ａ】
2009009590.tif 000032
【図２３Ｂ】
2009009590.tif 000033
【図２４Ａ】
2009009590.tif 000034
【図２４Ｂ】
2009009590.tif 000035
【図２５】
2009009590.tif 000036
【図２６Ａ】
2009009590.tif 000037
【図２６Ｂ】
2009009590.tif 000038
【図２７】
2009009590.tif 000039
【図２８Ａ】
2009009590.tif 000040
【図２８Ｂ】
2009009590.tif 000041
【図２８Ｃ】
2009009590.tif 000042
【図２９】
2009009590.tif 000043
【図３０Ａ】
2009009590.tif 000044
【図３０Ｂ】
2009009590.tif 000045
【図３１Ａ】
2009009590.tif 000046
【図３１Ｂ】
2009009590.tif 000047
【図３２】
2009009590.tif 000048
【図３３Ａ】
2009009590.tif 000049
【図３３Ｂ】
2009009590.tif 000050
【図３４】
2009009590.tif 000051
【図３５】
2009009590.tif 000052
【図３６Ａ】
2009009590.tif 000053
【図３６Ｂ】
2009009590.tif 000054
【図３７】
2009009590.tif 000055
【図３８】
2009009590.tif 000056