(57)【要約】  文書に対する寄与を管理するためのシステムおよび方法を提供する。寄与管理システムは、個々の変更それぞれに関する完全な情報を提供し、選択された変更のみを包含する文書のバージョンを取り出すことを可能にし、様々なエディタによって行われた変更における競合を解決することを容易にする。寄与管理システムは、文書内の各エレメントに一意の識別子を割り当てる。エディタは、特定の編集操作を識別された文書エレメントに実行することによって、文書を修正することができる。寄与管理システムは、エディタの変更を、実行された編集操作および変更されたエレメントの一意の識別子を包含する「寄与」として格納する。【特許請求の範囲】
【請求項１】
コンピュータシステムにおいて文書に対する寄与を表すための方法であって、
前記文書内の各エレメントに、持続性のある一意の識別子を割り当てることと、
修正されたエレメントを識別する編集操作を受信することと、
前記文書に対する寄与を、前記修正されたエレメントのエレメント識別子、および前記修正されたエレメントで実行された前記編集操作として格納することと
を含むことを特徴とする方法。
【請求項２】
前記文書は、ソースコードを包含することを特徴とする請求項１に記載の方法。
【請求項３】
前記文書は、インテンショナルツリーとして表されることを特徴とする請求項１に記載の方法。
【請求項４】
寄与を前記文書に格納することは、ドメイン特有のチェックを前記寄与に適用することを含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記文書は、テキストを包含し、各文字が前記文書内で一意に識別されたエレメントであることを特徴とする請求項３に記載の方法。
【請求項６】
前記編集操作は、エレメントを追加し、エレメントを除去し、エレメントを移動させ、エレメントをリネームし、エレメントを置換し、およびエレメントのプロパティを変更することから成るグループから選択されることを特徴とする請求項１に記載の方法。
【請求項７】
前記編集操作は、以前に削除された文書エレメントを回復させることを特徴とする請求項１に記載の方法。
【請求項８】
前記寄与を、以前に格納された寄与との競合に関してチェックすることを含むことを特徴とする請求項１に記載の方法。
【請求項９】
コンピュータシステムにおいて所望のバージョンの文書を回復させるための方法であって、
前記文書に対する１つまたは複数の寄与を包含するリポジトリから、それぞれが、前記文書に適用されるバージョンに対する寄与の全てを有する前記文書のバージョンを包含する、マイルストーンのリストを取り出すことと、
前記リポジトリ内の最も近いマイルストーンが、前記所望のバージョンの前記文書かを判定することと、
判定された前記最も近いマイルストーンを取り出すことと、
前記所望のバージョンの前記文書を回復させるために、前記マイルストーンにおける文書のバージョンと前記所望のバージョンの前記文書との間に介在する変更を処理することと
を含むことを特徴とする方法。
【請求項１０】
前記文書は、ソースコードを包含することを特徴とする請求項９に記載の方法。
【請求項１１】
最も近いマイルストーンのバージョンは、前記所望のバージョンの後の寄与を包含し、前記介在する変更を処理することが、前記所望のバージョンの後に行われた前記寄与を戻すことを含むことを特徴とする請求項９に記載の方法。
【請求項１２】
コンピュータシステムにおいてソース制御システム内の競合を管理するための方法であって、
ソースコードを包含する文書に対する第一の寄与を受信して前記ソース制御システムに格納することと、
前記第一の寄与との競合を包含する第二の寄与を受信することと、
ユーザが、前記第一の寄与および第二の寄与を見て前記競合を解決するために前記ソース制御システムを使用することができるように、前記ソース制御システムに第二の寄与を格納することと
を含むことを特徴とする方法。
【請求項１３】
前記文書は、インテンショナルツリーであり、前記競合は、ドメイン特有であることを特徴とする請求項１２に記載の方法。
【請求項１４】
前記ソース制御システムは、前記競合を自動的に解決するために、前記第二の寄与にチェックインするユーザから受信した前記情報を使用することを特徴とする請求項１２に記載の方法。
【請求項１５】
文書バージョンの管理のためのシステムであって、
文書内の新しいエレメントのために、持続性のある一意の識別子を生成するための一意の識別子生成コンポーネントと、
文書内のエレメントに対する変更を、変更された各エレメントのための識別子および各エレメントに対する変更を記述する操作タイプを包含する寄与として表すための寄与記述コンポーネントと、
前記文書に適用された寄与の順序を格納するためのヒストリリストコンポーネントと、
前記ヒストリリストおよび前記文書に対して行われた各寄与を格納するためのリポジトリコンポーネントと
を備えることを特徴とするシステム。
【請求項１６】
前記文書は、インテンショナルツリーとして表されることを特徴とする請求項１５に記載のシステム。
【請求項１７】
１つまたは複数のコンピュータメモリに集合的に格納される、文書に対する変更を表すためのデータ構造であって、
エレメントで実行される操作を記述する変更タイプと、
前記変更タイプに特有の情報、および変更された前記エレメントの一意の識別子を包含する変更データと、
前記変更データの一部ではない、変更と関連付けられる情報を包含する補足情報と
を備えることを特徴とするデータ構造。
【請求項１８】
前記変更タイプは、リネーム操作であり、前記変更データは、識別されたエレメントの古い名前および新しい名前を包含することを特徴とする請求項１７に記載のデータ構造。
【請求項１９】
前記変更タイプは、移動操作であり、前記変更データは、前記識別されたエレメントの古い位置および新しい位置を包含することを特徴とする請求項１７に記載のデータ構造。
【請求項２０】
前記変更タイプは、削除操作であることを特徴とする請求項１７に記載のデータ構造。
【請求項２１】
前記変更タイプは、追加操作であることを特徴とする請求項に１７に記載のデータ構造。
【請求項２２】
前記変更タイプは、書式設定する変更であり、前記変更データは、適用される新しい書式設定を記述することを特徴とする請求項１７に記載のデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書およびソースコードの制御のための方法およびシステムに関する。
【背景技術】
【０００２】
文書管理システム（document management system）は、一般に、いくつかのエディタ（editor）によって同時に編集される可能性がある文書を格納するために用いられる。各エディタは、文書をチェックアウトし（check out）、文書を変更し、新しいバージョン（version）の文書を文書管理システムにチェックインする(check in）ことができる。いくつかのエディタが同じ文書を変更すると、文書管理システムは通常、変更をチェックインするために各エディタがそれらの変更を最新版の文書に適用することを必要とする。
【０００３】
あるエディタが変更を文書にチェックインし、別のエディタがその文書を変更している場合、いくつかの文書管理システムは、第二のエディタの変更と他のエディタによって生成される新しいバーションの文書とを自動的にマージすることを試み、その結果、第二のエディタの変更をチェックインすることができる。文書がテキストを包含する場合、このマージは通常、テキストが追加、除去、または修正された箇所を判定するための共通のテキスト比較技法を使用することによって生じる。別のエディタが変更した文書の一部分をあるエディタが削除する場合、または各エディタが文書の同じ部分を修正する場合など、変更が競合する場合、文書管理システムにとって各エディタの変更をマージすることが難しいことがある。一部の文書管理システムは、ある変更が別の変更にどのように関連する可能性があるかを判定することさえできないので、この困難性は増大される。例えば、ある位置から別の位置に移動されたテキストと、ある位置から削除されたテキストおよび別の位置に追加される同様の新しいテキストとの間の相違を判定することは難しい。文書管理システムは、競合を解決するために、ユーザ介入（user intervention）に依拠することが多い。
【０００４】
文書管理システムは、エディタが文書をチェックアウトすることができる細分度（granularity）のレベルの点で異なる。例えば、本のための文書管理システムは、同時に１つの章（chapter）をチェックアウトできるようにし、ワープロ文書管理システムは、文書全体（例えば、ファイルレベルの細分度）のみをチェックアウトできるようにするか、または同時に１つの段落をチェックアウトできるようにする可能性がある。細分度のレベルに関わらず、潜在的な競合は、２つのエディタが文書の同じ部分をチェックアウトして修正するときに生じる。２つのエディタが同じファイルをチェックアウトするが、その異なるセクションを修正する場合、ほとんどの文書管理システムは、競合は生じなかったと判定し、両方のエディタが変更をチェックインすることを可能にすることができる。ユーザが、細かいレベルの細分度でチェックアウトするとき、エディタが、文書の同じチェックアウト部分を編集する可能性は低いので、競合の可能性は減少される。
【０００５】
あるエディタによって行われた変更を、別のエディタによって行われた変更とマージできないとき、競合が生じる。一部の文書管理システムは、第二のエディタが競合する変更をチェックインすることを防ぐことによって、競合に対処する。第二のエディタは、変更が第一のエディタの変更と競合しないように、その変更をあきらめるか、またはその変更を修正する可能性がある。他の文書管理システムは、第一のエディタの変更を上書きすることによって、またはエディタに文書ツリーに新しい枝を作成するように促すことによって、第二のエディタの変更をチェックインすることを可能する。枝は、一方に対する変更が他方に自動的には適用されないように、将来は独立に修正される２つまたはそれ以上に分岐したバーション（divergent version）の文書を作成する。
【０００６】
文書管理システムの１つのタイプは、ソースコードの本体に同時に取り組む複数のソフトウェア開発者のためのメカニズムを提供するソフトウェアソース制御システムである。ソースコードファイルは文書であり、各開発者はエディタである。典型的に、変更を十分にトラックし、ソースコードを、作業用の実行ファイル（working executable file）を作成するように構築することができるような状態に保つことがソース制御システムの目標である。多くの開発者が、同時に同じソースコードに取り組んでいる場合、競合が起こることが多く、連絡を取り合って全ての問題を修正できるようにどの開発者がそれぞれの変更を行ったのかを知ること、および、競合する変更が行われた後もなお正しく構築するソースコードのバーションを（例えば、競合する変更を適用しないことによって、またはオペレータに、競合の手動の解決が必要とされることを警告することによって）作成することができることが重要である。
【０００７】
文書管理システムは典型的に、サーバコンポーネントとクライアントコンポーネントから成る。サーバコンポーネントは通常、各文書を包含するデータベース、および各文書に対して行われる変更のレコード（例えば、チェックインのヒストリ）を維持する。サーバは、エディタがどの文書をチェックインしたかについてのレコードも維持しており、その結果、この情報を使用して、新しい変更がチェックインされるときにいずれか必要なマージを実行することができる。クライアントコンポーネントは通常、サーバと連絡をとりファイルをチェックインおよびチェックアウトするソフトウェア、ならびにファイルを修正するのに使用されるエディタから成る。
【０００８】
【特許文献１】米国特許第５７９０８６３号明細書
【特許文献２】米国特許第６０９７８８８号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００９】
これらの目標を達成するために、多くの現在の文書管理システムは、チェックインが行われる毎に完全なバージョン（complete version）の文書を格納し、全てのそのようなバージョンを取り出すことを可能にする。例えば、ユーザＡがある変更をある文書にチェックインし、次いでユーザＢがある変更をその文書にチェックインする場合、通常、それぞれの変更の前の文書のバージョン、Ａの変更後のバージョン（元＋Ａ）、およびＡとＢ両方の変更後のバージョン（元＋Ａ＋Ｂ）を取り出すことができる。これらのシステムの１つの問題は、文書がチェックインされたときに存在していたバージョンの文書以外を取り出すことができないことである。例えば、２つの変更が次々にチェックインされる場合、第一の変更の後の文書を取り出すことはできるが、第一の変更を包含せずに第二の変更を包含するバージョンの文書を取り出すことはできない。上記の例では、ユーザＡの変更にエラーがあることがわかった場合、ユーザＢの変更のみを含むバージョンを取り出すことが望まれるであろう。しかし、典型的な文書管理システムでは、Ａの変更を除去した新しい変更がチェックインされることを必要とするか、または、ＡとＢ両方の変更が除去され、その後にＢの変更が再適用されることを必要とするかのいずれかである。
【００１０】
現在の文書管理システムの別の問題は、競合が生じる場合、文書管理システムのオペレータが、競合する変更を選択することができるような詳細な情報が使用不可能であるということである。例えば、オペレータは、ユーザＡおよびユーザＢが上記の変更を行った後の文書のバージョンを見る場合、２つの変更を分けること、およびＢの変更の目的に対してＡの変更の目的は何かを理解することは難しい。
【課題を解決するための手段】
【００１１】
文書に対する寄与（contribution）を管理するための方法およびシステムを提供する。一部の実施形態では、寄与管理システム（contribution management system）は、個々の変更それぞれに関する完全な情報を提供し、選択された変更のみを包含するバージョンの文書を取り出すことを可能にし、様々なエディタによって行われる変更の競合を解決することをより容易にする。寄与管理システムは、文書内の各エレメントに一意の識別子を割り当てる。例えば、テキスト文書内の各文字または各単語は、文書エレメントとすることができる。エディタは、識別された文書エレメントに特定の編集操作を実行することによって、文書を修正することができる。例えば、ある編集操作は、あるエレメントを削除することができる。寄与管理システムは、エディタの変更を、実行された編集操作および修正されたエレメントの一意の識別子を包含する「寄与」として格納する。例えば、寄与は、削除操作、および削除された文書エレメントの識別子を包含することができる。したがって、寄与管理システムは、完全なバージョンの文書ではなく、エディタによって行われた変更のみを格納する。例えば、ユーザＡおよびユーザＢがある文書を変更する場合、Ａの変更を含む元の文書（元＋Ａ）を格納し、次いでＡおよびＢの変更を含む元の文書（元＋Ａ＋Ｂ）を格納するのではなく、そのシステムは、元の文書、ユーザＡの変更、およびユーザＢの変更を別々に格納する。このシステムは、単にどの変更が適用されるべきかを選択することによって、任意のバージョンの文書を取り出すことをできるようにする。例えば、ユーザが、ユーザＢの変更のみを包含するバージョンの文書を要求すると、寄与管理システムは、ユーザＢの変更を元の文書に適用して、要求されたバージョンを作成する。
【発明を実施するための最良の形態】
【００１２】
一部の実施形態では、寄与管理システムは、文書の存続期間（lifetime）の間持続性を有する一意の識別子を文書内のエレメントに割り当てる。一意の識別子の使用は、テキストがある位置から別の位置に移動される状況と、テキストが削除され、新しいテキストが追加される状況とを区別することを容易にすることなど、以前のテキスト比較技術の問題を克服することを助ける。一意の識別子が文書の存続期間の間持続性を有することによって、寄与管理システムは、ある変更で削除された文書エレメントが後の変更でいつ回復されるかを検出することもできる。一意の識別子は、寄与管理システムサーバなどによって中央に（centrally）作成されることがあり、または、クライアント識別番号を、エレメントがクライアントによって作成されるとインクリメントされる番号に加えることなどによって、各エディタのクライアントシステムで生成されることがある。
【００１３】
一部の実施形態では、文書エレメントは、ｉｎｔｅｎｔｉｏｎａｌ  ｔｒｅｅ（インテンショナルツリー）内のノードである。ｉｎｔｅｎｔｉｏｎａｌ  ｐｒｏｇｒａｍ  ｔｒｅｅ（インテンショナルプログラムツリー）として表されるコンピュータプログラムを生成し管理するためのシステムが説明されている（例えば、参照として本明細書に取り込まれる「Method and System for Generating and Displaying a computer Program」という名称の特許文献１、および「Method and System for Reducing an Intentional Program Tree Represented by High-Level Computational Constructs」という名称の特許文献２）。ｉｎｔｅｎｔｉｏｎａｌ  ｔｒｅｅを格納する文書は、固有の編成を有し、ツリーの各ノードは、文書における一意に識別可能なエレメントを形成する。ｉｎｔｅｎｔｉｏｎａｌ  ｔｒｅｅを包含する文書に対する寄与は、ノードを除去すること、追加すること、置換すること、リネームすることなどの、ツリーのノードに実行される操作を格納することができる。
【００１４】
一部の実施形態では、寄与管理システムは、複数のエディタにアクセス可能なリポジトリ内の文書に対する寄与を格納する。各エディタは、そのリポジトリにチェックインされる寄与を行い、他のエディタによって行われる寄与にアクセスすることができる。寄与管理システムは、エディタのクライアントコンピュータにおけるローカルキャッシュ内にリポジトリのコピーを保持することもでき、その結果、エディタはそのリポジトリから切断されているときもファイルを見ることができる。エディタは定期的に、リポジトリに、ローカルにキャッシュされたファイルをリポジトリ内のファイルと同期させるように指示することができる。同期化は、エディタのローカルキャッシュ内のファイルを、前回エディタが同期させた後にリポジトリにチェックインされた寄与の状態に更新する。エディタが、別のエディタによって変更されチェックアウトされたファイルを有する場合、寄与管理システムは、変更をローカルのコピーに適用することを試み、エディタに全ての競合を解決するように促すことがある。
【００１５】
一部の実施形態では、リポジトリは、各寄与を識別するヒストリリストを包含し、寄与がチェックインされたときに誰がその寄与を行ったかなどの補足情報（supplemental information）を格納する。ヒストリリストは、ある寄与をオペレータによって除去されたものとしてマーク付けすることによって、寄与管理システム内の過去の競合に対する解決を維持することもできる。エディタがリポジトリと同期をとるとき、競合していないそれらの変更のみが典型的に取り出される。一部の実施形態では、エディタは、これらの変更を正すことができるように、または前の正しくない変更から知るために、指定された競合文書を取り出すことができる。一部の実施形態では、ヒストリリストは、あるプロジェクトの分岐した複数のバージョンをトラックする複数のリストを包含する。例えば、ソフトウェアソース制御システムでは、第一のバージョンのプロダクトがリリースされる前にまだテストされている間に、第二のバージョンのプロダクトに取り組み始めるのが望ましいことが多い。ヒストリリストは、各バージョンの変更の進行をトラックする別個のリストを保持することによって、あるプロダクトの２つのバージョンに関する文書を管理することができる。そのような実施形態では、ヒストリリスト内のエントリは、文書に対して行われる各変更間の階層関係を格納するグラフを形成する。ある時点で、オペレータは、階層のあるパス（path）と関連付けられる寄与を、階層の別のパスにある寄与とマージしたいことがある。例えば、ソース制御システム内のソースコードは、リリースのためにテストされるプロセス内にある、あるパスを有することがあり、一方、別のパスはプロダクトの将来的なバージョンに対する作用を包含する。最初のバージョンが完成すると、最初のバージョンをテストしている間に見つかった全ての問題に対する修正（fix）を包含する変更を、プロダクトの将来的なバージョンに適用することが望ましいことが多い。
【００１６】
寄与管理システムは、２つのエディタによって行われる変更が競合するときにもチェックインが生じることを可能にする。２つのエディタが変更を行うのにかなり努力を費やした場合、後にこれらの変更が失われず競合を解決するように、これらの変更をチェックインすることを可能にすることが望ましいことがある。２つのエディタは、どの変更が正しいかについて意見が一致せず、第三のエディタが両方の変更を見てそれぞれの変更をレビューすることができるように望むこともある。寄与管理システムは、各変更について完全な情報を包含することとなり、システムのオペレータは、どの変更が除去されるべきかを選択することができる。オペレータは、作業が各バージョンの文書で他に影響を与えることなく継続できるように、ヒストリリスト内で２つの分岐したパスを包含する枝を作成することを選ぶこともある。
【００１７】
一部の実施形態では、寄与管理システムは、競合解決規則（conflict resolution rule）が変更に適用されることを可能にする。ソースコードの例では、寄与管理システムは、あるエディタが、別のエディタが修正する関数（function）を削除すると、解決する必要のある競合が存在するというワーニングがエディタそれぞれに送信されるように、ソースコード文書に設定される規則を適用することができる。しかし、両方の変更を、拒否するかまたは一方が他方を上書きするのではなく、チェックインすることができたので、エディタまたは別のオペレータは、競合を解決するための各変更について完全な情報を有しているであろう。一部の実施形態では、規則を設定して、競合を自動的に解決することができる。例えば、あるエディタは、別のエディタに対する上級性（seniority）を有することがあり、競合が存在するときは上級エディタ（senior editor）の変更が優位となるように、規則を設定することができる。
【００１８】
一部の実施形態では、寄与管理システムは、リポジトリ内にマイルストーンバージョン（milestone version）の文書を格納することがある。ある文書のマイルストーンの複数のバージョンは、特定の時間の前に文書に対して行われた全ての変更を包含する文書の複数バージョンである。寄与管理システムは、完全なバージョンの文書ではなく、各エディタによって行われた変更のみを格納するので、多くの変更が行われた後に個々の変更を適用することによって現在のバージョンの文書を構成することは、非効率的となる可能性がある。したがって、寄与管理システムは、マイルストーンバージョンの文書を、定期的な間隔でまたはオペレータによって選択されるときに格納する。ヒストリリストが、文書の分岐したパスを包含する場合、寄与管理システムは、各パスについてマイルストーンバージョンを維持することができる。寄与管理システムは、文書のマイルストーンバージョンを使用して、そのマイルストーンバージョンに近い、文書のバージョンをすばやく取り出す。例えば、マイルストーンバージョンの後の３つの変更を含む文書のバージョンが要求されると、寄与管理システムは、文書が作成されてからの全ての変更を適用するのではなく、マイルストーンバージョンを取り出して、３つの介在している変更を適用する。
【００１９】
一部の実施形態では、寄与管理システムは、複数のマイルストーンバージョンを使用して、あるマイルストーンバージョンより早い文書のバージョンを取り出す。例えば、マイルストーンバージョンの前の３つの変更を含む文書のバージョンが要求されると、寄与管理システムは、マイルストーンバージョンを取り出して、要求されたバージョンの文書を作成するために３つの介在している変更を戻す。
【００２０】
図１は、一実施形態における寄与管理システムのレイアウトを図示する。サーバ１０５は、文書に対して行われた変更の全てを格納するリポジトリ１１０、変更に競合がないかを調べる競合解決（conflict resolve）コンポーネント１１１、エディタのファイルについての要求に対してサービスを提供するチェックイン／チェックアウトコンポーネント１１２、オペレータがマイルストーンバージョンの文書を作成することを可能にするマイルストーン作成（milestone creation）コンポーネント１１３、および新しい文書エレメントに一意の識別子を生成する一意の識別子生成（unique identifier generation）コンポーネント１１４を包含する。サーバ１０５は、インターネットまたはローカルエリアネットワークなどのネットワーク１１５に接続される。クライアント１２０もネットワーク１１５に接続され、ベースバージョン（base version）１３５、寄与コンポーネント１２５、および編集アプリケーション１３０を包含する。ベースバージョン１３５は、クライアント１２０を使用するエディタが修正している、サーバ１０５から取り出されたバージョンである。寄与コンポーネント１２５は、エディタによって行われた各変更に対する寄与を作成し、寄与が寄与管理システムにチェックインされるまで寄与を格納する。編集アプリケーションは、エディタによって使用されて、寄与コンポーネント１２５によって寄与として格納される文書に対する変更を行う。一部の実施形態では、編集アプリケーションは、各寄与をすぐにサーバに伝え、寄与は、クライアントでローカルには格納されない。第二のクライアント１４０もネットワーク１１５に接続され、ベースバージョン１５５、編集アプリケーション１５０、および第二のクライアントを使用するエディタの寄与コンポーネント１４５を包含する。
【００２１】
システムが実装されるコンピューティング装置は、中央処理ユニット、メモリ、入力装置（例えば、キーボードおよびポインティングデバイス）、出力装置（例えば、ディスプレイ装置）、およびストレージデバイス（例えば、ディスクデバイス）を含むことができる。メモリおよびストレージデバイスは、システムを実装する命令を包含することができるコンピュータ読み取り可能な媒体である。さらに、データ構造およびメッセージ構造を、通信リンクの信号などのデータ伝送媒体を介して格納または伝送することができる。インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、ポイントツーポイントダイアルアップ接続、携帯電話ネットワークなどの様々な通信リンクを使用することができる。
【００２２】
このシステムの実施形態を、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能な家庭用電化製品、デジタルカメラ、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ならびに上記のシステムおよびデバイスの任意のものを含む分散コンピューティング環境などを含む様々なオペレーティング環境で実装することができる。コンピュータシステムは、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、パーソナルコンピュータ、プログラム可能な家庭用電化製品、およびデジタルカメラなどとすることができる。
【００２３】
このシステムは、１つまたは複数のコンピュータあるいは他のデバイスによって実行されるプログラムモジュールなどのコンピュータ実行可能な命令の一般的なコンテキストで記述することができる。通常、プログラムモジュールには、特定のタスクを実行するかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造などが含まれる。典型的には、プログラムモジュールの機能を様々な実施形態で望まれるように結合または分散することができる。
【００２４】
図２は、一実施形態における寄与管理システムサーバのコンポーネントを図示する。寄与管理システムサーバ２０５は、競合解決コンポーネント２１０、チェックイン／チェックアウトコンポーネント２１２、マイルストーン作成コンポーネント２１５、一意の識別子生成コンポーネント２１７、およびリポジトリ２２０を包含する。競合解決コンポーネント２１０は、チェックインされた変更に競合がないかを調べて、競合解決規則を適用することまたはオペレータに通知することなどの、競合を解決するために適切なステップを実行する。チェックイン／チェックアウトコンポーネントは、エディタが、文書をチェックインおよびチェックアウトすることを可能にし、チェックインされた文書のために競合解決コンポーネントを呼び出す。マイルストーン作成コンポーネント２１５は、そのバージョンに近い文書をすばやく取り出すことができるように、オペレータが、マイルストーンバージョンの文書に含まれるべき変更を指定することを可能にする。一意の識別子生成コンポーネント２１７は、エディタによって行われた変更に包含される新しい文書エレメントに、一意の識別子を生成する。リポジトリ２２０は、ヒストリリスト２２５、マイルストーンバージョンの文書２３０、および文書に対して行われた寄与２３５を包含する。ヒストリリスト２２５は、文書に対して行われた各寄与の間の関係を格納する。寄与２３５は、実行された操作、修正された文書エレメントの一意の識別子、および寄与を行ったエディタなどの他の補足情報を含め、文書に対して行われた各変更を記述する情報を包含する。
【００２５】
図３は、一実施形態における、寄与を格納するために寄与管理システムによって使用されるデータ構造を図示するブロック図である。寄与３０５は、変更タイプ３１０、変更データ３１５、および補足情報３２０を包含する。変更タイプ３１０は、識別されたエレメントで実行された編集操作のタイプを格納する。例えば、編集操作は、追加、削除、リネーム、移動、置換、書式設定（例えば、イタリック体）、または他のタイプの操作とすることができる。変更データ３１５は、実行された変更のタイプに特有のデータを示す。例えば、置換操作は、あるエレメントが別のエレメントで置換されることを可能にし、両方のエレメントの一意の識別子が変更データ内で指定される。移動操作は、エレメントの前の位置および新しい位置を指定するか、または移動されたエレメントが後に配置されるエレメントの一意の識別子を包含することができる。補足情報３２０は、寄与を行ったエディタおよび寄与が行われた時間など、寄与に関係する任意の追加的な情報を包含する。単一の編集セッションで行われたエディタの寄与のそれぞれがバッチとして同時にチェックインされる実施形態では、各寄与は、同じ補足情報を共有することができる。
【００２６】
図４は、一実施形態におけるクライアント寄与コンポーネントの処理を図示する流れ図である。コンポーネントは、エディタが文書に変更を行うたびに呼び出される。ブロック４１０では、コンポーネントは、修正された文書エレメントを編集アプリケーションから受信する。一部の実施形態では、寄与コンポーネントは、一意の識別子を、受信された全ての新しい文書エレメントに割り当てる。ブロック４１５では、コンポーネントは、修正されたエレメントで実行された変更タイプ、および任意の変更データ（移動操作のための新しい位置など）を受信する。ブロック４１７では、コンポーネントは、変更を記述する任意の補足情報を受信する。ブロック４２０では、コンポーネントは、各変更に関する変更タイプ、変更データ、および補足情報を包含する寄与を格納する。コンポーネントは、個々の寄与それぞれを、すぐにサーバに送信することによって格納することがあり、または、グループでサーバに送信するために寄与をバッチ処理することがある。コンポーネントは、寄与をサーバに送信する前に、エディタによる指示を待つこともある。
【００２７】
図５は、一実施形態における、寄与管理システムサーバのチェックアウトコンポーネントの処理を図示する流れ図である。コンポーネントは、エディタが特定のバージョンの文書を取り出そうとするときに呼び出される。ブロック５０５では、コンポーネントは、いずれの変更を適用するかを選択したエディタから取り出されるべきターゲットバージョン（target version）の文書を受信する。エディタは、特に適用されるべき各寄与を識別することがあり、または、その時点より前の変更が取り出されるべきであることを示す時点を指定することがある。ヒストリリストが、異なるプロダクトバージョンなどのための、文書の分岐したパスを包含する場合、エディタは、各枝を識別するために格納された枝の名前を指定することなどによって、どの文書のパスから変更を取り出したいと思っているかを指定することもできる。エディタは、競合のために除去されるようにマーク付けされた寄与が取り出されるべきか否かを、これらの寄与を具体的に選ぶこと、またはエディタは全ての寄与に関心があるということをフラグで示すことのいずれかによって選択することもできる。ブロック５１０では、コンポーネントは、リポジトリ内で使用可能なマイルストーンバージョンのリストを取り出す。ブロック５１５では、コンポーネントは、最も近いマイルストーンバージョンを判定する。判断ブロック５２０では、最も近いマイルストーンバージョンが、より早いバージョンである場合、コンポーネントはブロック５３０に続き、そうでない場合は、コンポーネントはブロック６２５に続く。ブロック６３０では、コンポーネントは、最も近いマイルストーンバージョンとターゲットバージョンの間に介在する全ての寄与（any intervening contributions）を適用する。ブロック５２５では、コンポーネントは、最も近いマイルストーンバージョンとターゲットバージョンの間に介在する全ての寄与を戻す。コンポーネントは次いで、要求されたバージョンの文書を返して完了する。
【００２８】
図６は、一実施形態における、寄与管理システムのチェックインコンポーネントの処理を図示する流れ図である。コンポーネントは、新しい寄与がリポジトリに追加されるときに呼び出される。ブロック６０５では、コンポーネントは、新しい寄与を受信する。ブロック６０７では、コンポーネントは、新しい識別子を、寄与に新しく追加された任意の文書エレメントに割り当てる。ブロック６１０では、コンポーネントは、前に受信された寄与との競合に関して新しい寄与をチェックする。判断ブロック６１５では、新しい寄与が競合を生じている場合、コンポーネントはブロック６２０に続き、そうでない場合は、コンポーネントは完了する。ブロック６２０では、コンポーネントは、競合を解決するためシステムのオペレータが後で使用するように、競合に関する情報を格納する。ブロック６２５では、コンポーネントは、システムのオペレータに競合を解決するように促す。コンポーネントは、電子メールを送信すること、またはオペレータのクライアントコンピュータにメッセージボックスを表示することなど、様々な方法でオペレータに促すことができる。ブロック６３０では、コンポーネントは、寄与を格納し、それをヒストリリストに追加する。次いで、コンポーネントは完了する。
【００２９】
図７は、文書に対し２つの変更を行った後の文書のバージョンの関係を図示するブロック図である。ベースバージョンＸ７０５の文書は、寄与Ａ７１０および寄与Ｂ７１５によって修正される。寄与Ａ７１０および寄与Ｂ７１５は、ヒストリリスト７３５に維持される。典型的には、寄与管理システムと同期をとるエディタは、オペレータによって除去されるようにマーク付けされていない、文書に対する全ての寄与を取り出す。しかし、寄与管理システムは、変更Ａのみ（バージョンＸ＋Ａ  ７２０）、変更Ｂのみ（バージョンＸ＋Ｂ  ７３０）、または両方（バージョンＸ＋Ａ＋Ｂ  ７２５）を包含する特定のバージョンの文書を取り出すことも可能にする。これは、エディタが、両方の変更を独立に調べることによって競合を解決しようとしているオペレータである場合に有用である。
【００３０】
図８ａおよび図８ｂは、２つの実施形態におけるヒストリリストを示すブロック図である。図８ａでは、単一のリスト８０５は、行われた複数の寄与を維持している。リストは、寄与Ａ８１０、Ｂ８１５、およびＣ８２０を包含する。寄与Ｂ８１５は、オペレータが競合または他の問題のため除去されるように寄与をマーク付けしたことを示す破線で示されている。このリストによって特定されたファイルの最新版を要求するエディタは、寄与ＡおよびＣのみを受信するが、エディタは、寄与Ｂが含まれる文書のバージョンを特に要求することもできる。図８ｂは、分岐したパスの文書が作成されたヒストリリスト８５０を図示する。ヒストリリストは、図８ａと同様に寄与Ａ８５５、Ｂ８６０、およびＣ８６５を包含する。ヒストリリストは、文書の一方のパスで寄与Ｃ８６５に続く寄与Ｄ８７０、および文書の他方のパスで寄与Ｃ８６５に続く寄与Ｘ８７５も包含する。ファイルの最新版を要求しているエディタは、取り出したい文書のパスを、パスを識別する枝の名前を指定することなどによって指定することもでき、または、パスが指定されない場合はデフォルトのパスとして、一方のパスがオペレータによって選択されることもある。
【００３１】
前述により、寄与管理システムの特定の実施形態を、本明細書に例示の目的で説明してきたが、本発明の精神および範囲から逸脱することなく様々な変形を行うことができることは理解されるであろう。例えば、ソフトウェアソース制御システムが例示として用いられていることを通じて、他の文書管理システムは、数人の著者が寄与する本に対する変更を格納するための出版システムなど、同様の技術に適用することができる。したがって、本発明は、添付の特許請求の範囲の記載によるものを除いては、限定されるものではない。
【図面の簡単な説明】
【００３２】
【図１】一実施形態における寄与管理システムのレイアウトを示す図である。
【図２】一実施形態における寄与管理システムサーバのコンポーネントを示す図である。
【図３】文書に対し２つの変更を行った後の文書のバージョンの関係を図示するブロック図である。
【図４】一実施形態における、寄与を格納するために寄与管理システムによって使用されるデータ構造を示すブロック図である。
【図５】一実施形態における、クライアントが文書をチェックインする処理を示す流れ図である。
【図６】一実施形態における、寄与管理システムサーバのチェックアウトコンポーネントの処理を示す流れ図である。
【図７】一実施形態における、寄与管理システムのチェックインコンポーネントの処理を図示する流れ図である。
【図８Ａ】一実施形態におけるヒストリリストを示すブロック図である。
【図８Ｂ】一実施形態におけるヒストリリストを示すブロック図である。
【図１】
2009515264.tif 000002
【図２】
2009515264.tif 000003
【図３】
2009515264.tif 000004
【図４】
2009515264.tif 000005
【図５】
2009515264.tif 000006
【図６】
2009515264.tif 000007
【図７】
2009515264.tif 000008
【図８Ａ】
2009515264.tif 000009
【図８Ｂ】
2009515264.tif 000010
【手続補正書】
【提出日】平成20年9月18日(2008.9.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータシステムにおいて文書に対する寄与を表すための方法であって、
前記文書内の各エレメントに、持続性のある一意の識別子を割り当てることと、
修正されたエレメントを識別する編集操作を受信することと、
前記文書に対する寄与を、前記修正されたエレメントの前記一意の識別子、および前記修正されたエレメントで実行された前記編集操作として格納することと
を含むことを特徴とする方法。
【請求項２】
前記文書は、ソースコードを包含することを特徴とする請求項１に記載の方法。
【請求項３】
前記文書は、インテンショナルツリーとして表されることを特徴とする請求項１に記載の方法。
【請求項４】
寄与を前記文書に格納することは、ドメイン特有のチェックを前記寄与に適用することを含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記文書は、テキストを包含し、各文字が前記文書内で一意に識別されたエレメントであることを特徴とする請求項３に記載の方法。
【請求項６】
前記編集操作は、エレメントを追加し、エレメントを除去し、エレメントを移動させ、エレメントをリネームし、エレメントを置換し、およびエレメントのプロパティを変更することから成るグループから選択されることを特徴とする請求項１に記載の方法。
【請求項７】
前記編集操作は、以前に削除された文書エレメントを回復させることを特徴とする請求項１に記載の方法。
【請求項８】
前記寄与を、以前に格納された寄与との競合に関してチェックすることを含むことを特徴とする請求項１に記載の方法。
【請求項９】
コンピュータシステムにおいて所望のバージョンの文書を回復させるための方法であって、
前記文書に対する１つまたは複数の寄与を包含するリポジトリから、それぞれが、前記文書に適用されるバージョンに対する寄与の全てを有する前記文書のバージョンを包含する、マイルストーンのリストを取り出すことと、
前記リポジトリ内の最も近いマイルストーンが、前記所望のバージョンの前記文書かを判定することと、
判定された前記最も近いマイルストーンを取り出すことと、
前記所望のバージョンの前記文書を回復させるために、前記マイルストーンにおける文書のバージョンと前記所望のバージョンの前記文書との間に介在する変更を処理することと
を含むことを特徴とする方法。
【請求項１０】
前記文書は、ソースコードを包含することを特徴とする請求項９に記載の方法。
【請求項１１】
最も近いマイルストーンのバージョンは、前記所望のバージョンの後の寄与を包含し、前記介在する変更を処理することが、前記所望のバージョンの後に行われた前記寄与を戻すことを含むことを特徴とする請求項９に記載の方法。
【請求項１２】
コンピュータシステムにおいてソース制御システム内の競合を管理するための方法であって、
ソースコードを包含する文書に対する第一の寄与を受信して前記ソース制御システムに格納することと、
前記第一の寄与との競合を包含する第二の寄与を受信することと、
ユーザが、前記第一の寄与および第二の寄与を見て前記競合を解決するために前記ソース制御システムを使用することができるように、前記ソース制御システムに第二の寄与を格納することと
を含むことを特徴とする方法。
【請求項１３】
前記文書は、インテンショナルツリーであり、前記競合は、ドメイン特有であることを特徴とする請求項１２に記載の方法。
【請求項１４】
前記ソース制御システムは、前記競合を自動的に解決するために、前記第二の寄与にチェックインするユーザから受信した前記情報を使用することを特徴とする請求項１２に記載の方法。
【請求項１５】
文書バージョンの管理のためのシステムであって、
文書内の新しいエレメントのために、持続性のある一意の識別子を生成するための一意の識別子生成コンポーネントと、
文書内のエレメントに対する変更を、変更された各エレメントのための識別子および各エレメントに対する変更を記述する操作タイプを包含する寄与として表すための寄与記述コンポーネントと、
前記文書に適用された寄与の順序を格納するためのヒストリリストコンポーネントと、
前記ヒストリリストおよび前記文書に対して行われた各寄与を格納するためのリポジトリコンポーネントと
を備えることを特徴とするシステム。
【請求項１６】
前記文書は、インテンショナルツリーとして表されることを特徴とする請求項１５に記載のシステム。
【請求項１７】
１つまたは複数のコンピュータメモリに集合的に格納される、文書に対する変更を表すためのデータ構造であって、
エレメントで実行される操作を記述する変更タイプと、
前記変更タイプに特有の情報、および変更された前記エレメントの一意の識別子を包含する変更データと、
前記変更データの一部ではない、変更と関連付けられる情報を包含する補足情報と
を備えることを特徴とするデータ構造。
【請求項１８】
前記変更タイプは、リネーム操作であり、前記変更データは、識別されたエレメントの古い名前および新しい名前を包含することを特徴とする請求項１７に記載のデータ構造。
【請求項１９】
前記変更タイプは、移動操作であり、前記変更データは、前記識別されたエレメントの古い位置および新しい位置を包含することを特徴とする請求項１７に記載のデータ構造。
【請求項２０】
前記変更タイプは、削除操作であることを特徴とする請求項１７に記載のデータ構造。
【請求項２１】
前記変更タイプは、追加操作であることを特徴とする請求項に１７に記載のデータ構造。
【請求項２２】
前記変更タイプは、書式設定する変更であり、前記変更データは、適用される新しい書式設定を記述することを特徴とする請求項１７に記載のデータ構造。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００２７
【補正方法】変更
【補正の内容】
【００２７】
図５は、一実施形態における、寄与管理システムサーバのチェックアウトコンポーネントの処理を図示する流れ図である。コンポーネントは、エディタが特定のバージョンの文書を取り出そうとするときに呼び出される。ブロック５０５では、コンポーネントは、いずれの変更を適用するかを選択したエディタから取り出されるべきターゲットバージョン（target version）の文書を受信する。エディタは、特に適用されるべき各寄与を識別することがあり、または、その時点より前の変更が取り出されるべきであることを示す時点を指定することがある。ヒストリリストが、異なるプロダクトバージョンなどのための、文書の分岐したパスを包含する場合、エディタは、各枝を識別するために格納された枝の名前を指定することなどによって、どの文書のパスから変更を取り出したいと思っているかを指定することもできる。エディタは、競合のために除去されるようにマーク付けされた寄与が取り出されるべきか否かを、これらの寄与を具体的に選ぶこと、またはエディタは全ての寄与に関心があるということをフラグで示すことのいずれかによって選択することもできる。ブロック５１０では、コンポーネントは、リポジトリ内で使用可能なマイルストーンバージョンのリストを取り出す。ブロック５１５では、コンポーネントは、最も近いマイルストーンバージョンを判定する。判断ブロック５２０では、最も近いマイルストーンバージョンが、より早いバージョンである場合、コンポーネントはブロック５３０に続き、そうでない場合は、コンポーネントはブロック５２５に続く。ブロック５３０では、コンポーネントは、最も近いマイルストーンバージョンとターゲットバージョンの間に介在する全ての寄与（any intervening contributions）を適用する。ブロック５２５では、コンポーネントは、最も近いマイルストーンバージョンとターゲットバージョンの間に介在する全ての寄与を戻す。コンポーネントは次いで、要求されたバージョンの文書を返して完了する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００２８
【補正方法】変更
【補正の内容】
【００２８】
図６は、一実施形態における、寄与管理システムのチェックインコンポーネントの処理を図示する流れ図である。コンポーネントは、新しい寄与がリポジトリに追加されるときに呼び出される。ブロック６０５では、コンポーネントは、新しい寄与を受信する。ブロック６０７では、コンポーネントは、新しい識別子を、寄与に新しく追加された任意の文書エレメントに割り当てる。ブロック６１０では、コンポーネントは、前に受信された寄与との競合に関して新しい寄与をチェックする。判断ブロック６１５では、新しい寄与が競合を生じている場合、コンポーネントはブロック６２０に続き、そうでない場合は、コンポーネントはブロック６３０に続く。ブロック６２０では、コンポーネントは、競合を解決するためシステムのオペレータが後で使用するように、競合に関する情報を格納する。ブロック６２５では、コンポーネントは、システムのオペレータに競合を解決するように促す。コンポーネントは、電子メールを送信すること、またはオペレータのクライアントコンピュータにメッセージボックスを表示することなど、様々な方法でオペレータに促すことができる。ブロック６３０では、コンポーネントは、寄与を格納し、それをヒストリリストに追加する。次いで、コンポーネントは完了する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００３２
【補正方法】変更
【補正の内容】
【００３２】
【図１】一実施形態における寄与管理システムのレイアウトを示す図である。
【図２】一実施形態における寄与管理システムサーバのコンポーネントを示す図である。
【図３】一実施形態における、寄与を格納するために寄与管理システムによって使用されるデータ構造を示すブロック図である。
【図４】一実施形態における、クライアント寄与コンポーネントの処理を図示する流れ図である。
【図５】一実施形態における、寄与管理システムサーバのチェックアウトコンポーネントの処理を示す流れ図である。
【図６】一実施形態における、寄与管理システムのチェックインコンポーネントの処理を図示する流れ図である。
【図７】文書に対し２つの変更を行った後の文書のバージョンの関係を図示するブロック図である。
【図８Ａ】一実施形態におけるヒストリリストを示すブロック図である。
【図８Ｂ】一実施形態におけるヒストリリストを示すブロック図である。
【国際調査報告】
2009515264.tif 000011