合併電子文檔的多個不同版本的方法和裝置的製作方法
2023-09-19 08:19:30
專利名稱：合併電子文檔的多個不同版本的方法和裝置的製作方法
技術領域：
本發明涉及軟體開發，更具體地說，涉及軟體開發工具。
背景技術：
現代軟體本質上很複雜並且通常由許多不同文檔的集合形成。由於文檔自身的大小和複雜性可以很重要，所以通常的做法是將開發和維護每個文檔的責任指派給一組開發者。當兩個開發者更改同一文檔時，有必要將每個個人和/或團隊的貢獻組合成將被結合到軟體內部版本(build)中的單個文檔。
一種基於軟體的工具(稱為合併工具)能夠將不同個人或團隊的貢獻組合成合併後的文檔。通常，合併工具自動地比較兩個或更多文檔是將被組合的不同文檔還是同一文檔的不同版本。所述文檔可以是單獨的文件，包括但不限於，原始碼文件、建模語言文件或其它電子文檔。被比較的文檔之間的任何差異(稱為增量)都被合併工具所標識。每個增量可以是指定對基線文檔做出的一個或多個更改的軟體對象或其它數據結構。
傳統的合併工具可以接受從兩個或更多文檔的比較生成的增量並將更改寫入合併後的文檔。被接受的增量被在基線文檔上實現以生成合併後的文檔。在這樣做時，合併工具通常就從文檔的每個不同版本標識的增量是否彼此衝突進行有限的分析。此類分析可以包括在將要合併的文檔之間進行逐行比較或者在某些情況下進行「組塊」分析。但是，合併工具並不分析文檔的結構以確定相關性和內部引用，以便確保保持合併後的文檔的完整性。
為了說明，當合併原始碼文檔的兩個或更多不同版本時，一個開發者可以向現有方法添加引用，同時另一個開發者可以刪除同一方法。兩個增量將被傳統的合併工具所標識。但是，由於更改發生在文檔的不同部分，傳統的合併工具將不會檢測出引用被破壞。也就是說，傳統的合併工具所執行的分析不會檢測出來自依賴於另一個開發者移除或刪除的原始碼部分的開發者的貢獻。結果，兩個增量都將被接受到合併後的文檔中。這產生了具有對不再存在的方法的引用的合併後的文檔。合併後的文檔不再保持引用的完整性。
這只是使用傳統的合併工具可以出現的一類問題的一個實例。由於傳統的合併工具不能理解正在被合併的文本的句法或語義，所以在合併操作期間檢測這樣的錯誤就成了問題。這種類型的錯誤直到原始碼被編譯時才能被檢測到。但是在開發過程中，編譯發生在晚於合併的時間，從而耽擱了開發者察覺到任何潛在問題的時間。晚期檢測引起了開發過程的額外成本和時間。
發明內容
本發明提供了一種用於將電子文檔合併為合併後的文檔的解決辦案。本發明的一個實施例可以包括一種合併結構化的電子文檔的多個不同版本的方法。所述方法可以包括標識所述電子文檔的多個不同版本，其中所述電子文檔具有定義的結構。所述方法還可以包括確定所述不同版本之間的多個增量和根據所述電子文檔的所述定義的結構來確定所述多個增量中的單個增量之間的關係。根據所述確定的關係，一個或多個所述增量可以被有選擇地接受以創建合併後的電子文檔。
本發明的另一個實施例可以包括機器可讀存儲器，其被編程以使機器執行此處所述的各個步驟。
附圖中示出了當前優選的實施例；但是可以理解，本發明並不限於示出的精確布置和工具圖1是示出了根據本發明的一個實施例的用於合併電子文檔的系統的示意圖；圖2是示出了根據本發明的另一個實施例的從將被合併的電子文檔的不同版本的比較中標識的增量的表；圖3是示出了由圖2的表所指定的先決條件關係的有向圖；圖4是示出了由圖2的表所指定的從屬關係的有向圖；圖5是示出了根據本發明的另一個實施例的從將被合併的電子文檔的不同版本的比較中標識的增量的表；圖6是示出了由圖5的表所指定的先決條件關係的有向圖；圖7是示出了由圖5的表所指定的從屬關係的有向圖；圖8是示出了根據本發明的另一個實施例的合併電子文檔的方法的流程圖。
具體實施例方式
本發明提供了一種用於合併電子文檔的解決辦案。在本發明的一個實施例中，可以標識衝突的增量並提供通知，從而警告開發者存在衝突。這樣的通知允許開發者在進行到開發過程的下一個階段之前對被合併的電子文檔執行任何需要的編輯。在另一個實施例中，可以標識增量之間的關係，例如某一增量是否依賴於另一個增量，或者是另一個增量的先決條件。可以應用一組規則來從合併後的文檔確定哪個增量將被接受或拒絕。
圖1是示出了根據本發明的一個實施例的用於合併電子文檔的系統的示意圖。如此處所使用的術語文檔指軟體模塊或其他結構化的電子文件。所述文件可以指定文本，包括但不限於，原始碼、基於計算機的描述語言、腳本語言和/或建模語言。在一個實施例中，例如，文檔可以是以JAVA程式語言編寫的大型程序的單個部分。但是，也可以使用其它程式語言(無論是高級還是低級)。在另一個實施例中，文檔可以包括通用建模語言(UML)，其是一種用於表達面向對象的分析和設計決策的標準。這樣的文檔可以是原始碼文件或者來自於原始碼文件。在這種情況下，文檔105和110可以是同一文件的不同版本。
合併工具100可以被實現為在諸如臺式計算機系統、膝上型計算機系統、伺服器之類的(以下稱為「計算機系統」)適合的信息處理系統中執行的一個或多個電腦程式。如圖所示，合併工具100可以獲得一個或多個文檔105和110。合併工具100可以包括一組用於標識文檔105、110之間的差異或更改(稱為增量)的規則。所述規則還可以指定其中增量將被接受以生成合併後的文檔115的次序和方式。將參考圖2-7更詳細地說明合併工具100所使用的規則。在任何情況下，規則向合併工具提供了與將被處理的文檔的結構有關的語義和句法知識。
通常，文檔105、110中的一個文檔被選擇為基線文檔。在這種情況下，例如，文檔105可以被選擇為基線文檔。相應地，合併工具100將文檔110與基線文檔105進行比較。在兩個文檔105與110之間標識的任何增量可以被從基線文檔105的角度來表達。也就是說，如果基線文檔105與文檔110的比較指示文檔110包括從基線文檔105遺失的構造，則可以生成添加增量。所述添加增量指定包括在文檔110中但從基線文檔105中遺失的軟體構造將被添加到基線文檔105。類似地，如果基線文檔105包括從文檔110遺失的軟體構造，則可以生成刪除增量。所述刪除增量指定沒有包括在文檔110中的基線文檔105中的軟體構造將被從基線文檔105刪除。
其它種類的增量可以包括更改增量和移動增量。更改增量可以指示基線文檔105中的特定軟體構造不同於文檔110中的相同或並行構造。儘管這些構造在某些方面彼此不同，但是兩個構造可以位於每個文檔內的相同相對位置。更改增量可以指定基線文檔105中的軟體構造將被更改以與文檔110中其對應的軟體構造相匹配。
移動增量可以指示與文檔110中的同一軟體構造的位置相比，基線文檔105中的特定軟體構造位於不同的相對位置。移動增量可以指定基線文檔105中的軟體構造將被移動以與文檔110中的軟體構造的位置相對應。
軟體構造(或構造)指用於特定目的的數據結構。構造可以指單個程式語言語句或多於一個語句的集合，例如循環、方法、函數等，其中所述集合具有特定的功能。構造還由諸如電氣和電子工程師協會(IEEE)和美國國家標準化組織(ANSI)之類的組織定義。這些組織提出用於不同的基於計算機的編程、腳本和/或建模語言(例如C、C++等)的標準。
圖2是示出了根據本發明的另一個實施例的從將被合併的文檔的不同版本的比較中標識的增量的表200。如圖所示，表200的第一列指示增量標號1、2或3。第二列(標題為「元素更改」)指示由每個增量指定的更改。在這種情況下，每個增量是由「+」符號前綴表示的添加增量。符號「E」指元素，其可以是先前所述的任何種類的不同軟體構造的簡寫。
表200的第三列(具有標題「引用的元素(多個)」)指定由將被添加的元素所引用的特定的一個或多個元素。「引用的元素(多個)」列中的元素還是所標識的增量的主體(subject)。也就是說，引用的元素還已被標識用於添加還是刪除。因此，增量1是指定元素2(或E2)將被添加的添加增量。如表200所指示的，+E2包括對E3的引用。增量2是指定E3將被添加的添加增量。+E3包括對E4的引用。增量3是指定E4將被添加的添加增量。+E4不包括對其它增量的引用。
回顧表200，應當指出，增量與增量所引用的元素之間的關係必須被遵守以維護引用的完整性。也就是說，如果+E2被接受以便被包括到合併後的文檔中，由於+E2引用了E3，+E3也必須被接受。繼續地，如果+E3將被接受，由於+E3引用了E4，E4也必須被接受。
圖3是示出了由圖2的表所指定的和由連接增量的實線箭頭所指示的先決條件關係的有向圖。圖3描述了先決條件添加增量關係和用於處理這樣的增量的規則。當添加增量被合併工具接受時，先決條件添加關係必須被遵守以維護引用的整體性。先決條件添加增量關係可以被定義為如下給定兩個添加增量D1和D2，如果D1包括由D2包括的添加元素所引用的添加元素，則D1是D2的先決條件。
通常，如果特定的添加增量(稱為目標添加增量)被考慮接受到合併後的文檔，則所有用於該目標添加增量的先決條件添加增量必須首先被接受。所述目標增量和所述目標的任何先決條件增量可以被看作將作為組被接受的原子單元。圖3指示如果增量+E2被選擇為目標並被考慮接受，則增量+E4和+E3必須被接受。增量+E4必須首先被接受，隨後是增量+E3。如果增量+E3被選擇為目標並被考慮接受，則增量+E4必須首先被接受。因此，增量+E4是增量+E3的先決條件。類似地，增量+E3是增量+E2的先決條件。在此實例中，如果增量+E3被接受，則不必接受增量+E2。類似地，如果增量+E4被接受，則不必接受增量+E3或+E2。
圖4是示出了由圖2的表所指定的和由虛線指示的從屬關係的有向圖。圖4描述了從屬添加關係和用於處理這樣的增量的規則。當(或如果)添加增量被合併工具拒絕時，這些從屬添加關係必須被遵守以維護引用的整體性。從屬添加增量關係可以被定義為如下給定兩個添加增量D1和D2，如果D1是D2的先決條件，則D2是D1的從屬。通常，為了拒絕目標添加增量，所有依賴該目標添加增量的添加增量都必須先於目標增量被拒絕。目標增量和任何從屬添加增量可以被看作將作為組被拒絕的原子單元。
圖4示出了增量+E2依賴增量+E3並且增量+E3依賴增量+E4。為了說明，如果增量+E3被選擇為目標增量並考慮用於拒絕，則增量+E2必須先於該目標被拒絕。值得注意地，在這種情況下增量+E4無需被拒絕。如果增量+E4被選擇為目標並考慮用於拒絕，則增量+E2必須首先被拒絕，隨後是增量+E3。增量+E2和+E3都在目標增量+E4之前被拒絕。在另一個實例中，如果增量+E2被選擇為目標並考慮用於拒絕，則增量+E3和增量+E4都無需被拒絕。
下表描述了兩個文檔(版本1和版本1.1)之間的實例合併，其中版本1是基線文檔。當比較兩個版本時，合併標識了增量+E2、+E3和+E4。雖然以下示出的實例說明了以標記語言格式(例如可擴展標記語言(XML))指定文檔的情況，但是應當理解，本發明並不局限於此。例如，本發明可以被應用於資料庫模式或任何二進位數據。
圖5是示出了根據本發明的另一個實施例的從將被合併的文檔的不同版本的比較中標識的增量的表500。如圖所示，表500示出了另一組增量1、2和3。在這種情況下，每個增量是由元素描述之後的「-」符號後綴表示的刪除增量。表500的第三列指定了由將被刪除的每個元素引用的特定的元素。如所指出的，「引用的元素(多個)」列中列出的元素也是標識的增量的主體。也就是說，引用的元素也已被標識用於刪除。
因此，增量1是指定E2將被刪除的刪除增量。E2引用另一個元素E3。增量2是指定E3將被刪除的刪除增量。E3-包括對E4的引用。增量3是指定E4將被刪除的刪除增量。E4-不包括對其他元素的引用。標識的增量與「引用的元素(多個)」列中列出的元素(即，那些由將被刪除的元素引用的元素)之間的關係必須被遵守以維護引用的完整性。因此，如果增量E3-在合併文檔中被接受—意味著增量E3將被刪除，則增量E2-也必須被接受，從而導致增量E2的移除。
圖6是示出了由圖5的表所指定的先決條件關係的有向圖。圖6描述了先決條件刪除增量關係和相應的規則。當刪除增量被接受時，先決條件刪除增量關係必須被遵守以維護引用的完整性。先決條件刪除增量關係可以被定義為如下給定兩個刪除增量D1和D2，如果D1包括引用了D2所包括的刪除元素的刪除元素，則D1是D2的先決條件。
通常，如果刪除增量被選擇為目標並考慮用於接受，則在接受所述目標之前，所述目標的所有先決條件刪除增量必須被接受。目標刪除增量和任何先決條件刪除增量可以被看作將作為組被接受的原子單元。如圖6所示，增量E2-是增量E3-的先決條件並且增量E3-是增量E4-的先決條件。因此，如果增量E3-被選擇為目標並考慮用於接受，則增量E2-必須首先被接受。但是，增量E4-無需被接受。如果增量E4-被選擇為目標並考慮用於接受，則增量E2-必須首先被接受，隨後是增量E3-，然後是增量E4-。最終，如果增量E2-被選擇為目標並考慮用於接受，則在接受增量E2-之前，增量E3-或增量E4-都無需被接受。
圖7是示出了由圖5的表所指定的從屬關係的有向圖。圖7描述了從屬刪除增量關係和用於處理這樣的關係的規則。從屬刪除增量關係可以被定義為如下給定兩個刪除增量D1和D2，如果D1是D2的先決條件，則D2是D1的從屬。通常，如果刪除增量被選擇為目標增量並考慮用於拒絕，則該目標增量的所有從屬刪除增量必須首先被拒絕。目標刪除增量和所述目標的從屬刪除增量可以被看作將作為組被拒絕的原子單元。
如圖7所示，如果增量E3-被選擇為目標並考慮用於拒絕，則增量E4-必須先於該目標而被拒絕。但是，不必拒絕增量E2-。如果增量E2-被拒絕，則增量E4-必須首先被拒絕，而後是增量E3-，繼之以增量E2-。如果增量E4-被選擇為目標並考慮用於拒絕，則增量E3-和增量E4-都無需被拒絕。
下表描述了兩個文檔(版本1和版本1.1)之間的實例合併，其中版本1是基線文檔。當比較兩個版本時，合併標識了增量E2-、E3-和E4-。如所指出的，儘管所示實例說明了以標記語言格式指定文檔的情況，但是應當理解，本發明並不局限於此。
圖8是示出了根據本發明的另一個實施例的合併文檔的不同版本的方法800的流程圖。方法800可以由參考圖1描述的合併工具來執行。方法800開始於步驟805，在步驟805，可以標識兩個或更多將被合併的文檔。如所指出的，所述文檔可以是同一文檔的不同版本。在步驟810，使用一個版本作為基線文檔，文檔的不同版本可以被分析以標識每個版本之間的增量。
在步驟815，合併工具可以確定標識的每個增量的類型。例如，每個增量根據情況可以被分類為刪除增量或添加增量。在步驟820，可以確定標識的增量之間的關係。也就是說，根據稱為目標增量的其它增量，增量可以被分類為從屬或先決條件。應當理解，雖然可以構造如此處所述的有向圖以便分類增量關係，但是無需生成此類數據結構。
在步驟825，判定是否有任何增量彼此衝突。可以根據在增量之間標識的關係來做出衝突是否存在的判定。例如，如果一個增量指定移除由另一個增量添加的元素所引用的元素，則存在衝突。當合併工具具有語義和句法處理能力時(就具有定義的結構的文檔而言)可以做出判定。所述結構可以由文檔類型或其中包括的文本和/或語言的類型來定義。如果存在衝突，所述方法可以繼續到步驟830。如果不存在，所述方法可以繼續到步驟835，在步驟835，增量可以被接受。
在步驟830，合併工具可以可選地提供衝突的可聽和/或視覺通知。進而，合併工具可以提供對衝突性質的描述。所述描述可以包括諸如衝突增量、由衝突增量引用的元素、由於衝突增量而將被添加或移除的元素、破壞的引用之類的信息。也可以向計算機操作者提供是允許合併工具根據此處描述的規則繼續自動的合併還是停止合併過程的選擇。因此，如果希望，操作者可以停止處理以有利於編輯文檔以便糾正標識的一個或多個衝突。
在步驟840，根據所述關係，增量可以被有選擇地接受到合併後的文檔中。例如，給定目標增量的所有先決條件增量可以在接受所述目標增量之前被遞歸地接受。給定目標增量的所有從屬增量可以在接受所述目標增量之前被遞歸地拒絕。合併工具可以應用此處描述的規則來確定是否接受和/或拒絕特定的增量。如所指出的，使用此處描述的規則，一個或多個增量的特定集合可以被看作可以作為組被接受或拒絕的原子單元。
此處披露的發明布置提供了一種用於在兩個或更多文檔上執行合併的解決方案。通常，合併工具編程有將被合併的文本和/或文檔類型的構造和結構知識。因此，合併工具可以標識增量、應用一個或多個規則來標識增量之間的關係，以及根據規則和/或關係來有選擇地接受或拒絕增量。這樣，本發明可以合併兩個或更多文檔，或者合併文檔的不同版本，使得這些文檔內的引用完整性得到維護。
本發明可以以硬體、軟體或硬體和軟體的組合來實現。本發明可以以集中的方式在一個計算機系統中實現或者以分布的方式實現，在所述分布方式中，不同部件可以跨多個互連的計算機系統分布。任何種類的計算機系統或其它適於執行此處所述的方法的裝置都是適合的。典型的硬體和軟體的組合可以是具有電腦程式的通用計算機系統，當所述程序被加載和執行時，所述程序控制所述計算機系統以使得其執行此處所述的方法。
本發明還可以被嵌入電腦程式產品，其包括允許實現此處所述的方法的所有特徵，並且當被加載到計算機系統中時，其能夠執行這些方法。當前上下文中的電腦程式或軟體是指一組指令的以任何語言、代碼或符號表示的任何表達，旨在使具有信息處理能力的系統直接執行特定的功能，或者執行以下兩者之一或全部後執行特定的功能a)轉換為另一種語言、代碼或符號；b)以不同的材料形式再現。
在不偏離本發明的精神或本質屬性的情況下，可以以其它形式來實施本發明。因此，應當參考以下權利要求，而不是上述說明書，以此作為本
權利要求
1.一種在軟體開發過程期間合併電子文檔的多個不同版本的方法，所述方法包括標識所述電子文檔的所述多個不同版本，其中所述電子文檔具有定義的結構；確定所述不同版本之間的多個增量；根據所述電子文檔的所述定義的結構來確定所述多個增量中的單個增量之間的關係；以及根據所述確定的關係有選擇地接受所述多個增量中的至少一個增量以創建合併後的電子文檔。
2.根據權利要求1的方法，所述確定關係的步驟包括將來自所述多個增量的至少一個增量標識為關於目標增量的先決條件增量。
3.根據權利要求2的方法，所述有選擇地接受增量的步驟包括在接受所述目標增量之前遞歸地接受所有先決條件增量。
4.根據權利要求1的方法，所述確定關係的步驟包括將來自所述多個增量的至少一個增量標識為關於目標增量的從屬增量。
5.根據權利要求4的方法，所述有選擇地接受增量的步驟包括在拒絕所述目標增量之前遞歸地拒絕所有從屬增量。
6.根據權利要求1的方法，所述確定關係的步驟包括將來自所述多個增量的至少第一增量標識為先決條件增量或從屬增量。
7.根據權利要求6的方法，還包括將所述至少第一增量標識為添加增量。
8.根據權利要求6的方法，還包括將所述至少第一增量標識為刪除增量。
9.根據權利要求6的方法，還包括將所述至少第一增量標識為移動增量。
10.根據權利要求6的方法，還包括將所述至少第一增量標識為更改增量。
11.根據權利要求1的方法，還包括在所述有選擇地接受增量的步驟之前，檢測至少兩個增量之間的衝突；以及提供所述衝突的通知。
12.一種機器可讀存儲器，其上存儲有具有多個代碼部分的電腦程式，所述代碼部分可由機器執行以使得所述機器執行以下步驟標識電子文檔的多個不同版本，其中所述電子文檔具有定義的結構；確定所述不同版本之間的多個增量；根據所述電子文檔的所述定義的結構來確定所述多個增量中的單個增量之間的關係；以及根據所述確定的關係有選擇地接受所述多個增量中的至少一個增量以創建合併後的電子文檔。
13.根據權利要求12的機器可讀存儲器，所述確定關係的步驟包括將來自所述多個增量的至少一個增量標識為關於目標增量的先決條件增量。
14.根據權利要求13的機器可讀存儲器，所述有選擇地接受增量的步驟包括在接受所述目標增量之前遞歸地接受所有先決條件增量。
15.根據權利要求12的機器可讀存儲器，所述確定關係的步驟包括將來自所述多個增量的至少一個增量標識為關於目標增量的從屬增量。
16.根據權利要求15的機器可讀存儲器，所述有選擇地接受增量的步驟包括在拒絕所述目標增量之前遞歸地拒絕所有從屬增量。
17.根據權利要求12的機器可讀存儲器，所述確定關係的步驟包括將來自所述多個增量的至少第一增量標識為先決條件增量或從屬增量。
18.根據權利要求17的機器可讀存儲器，還包括將所述至少第一增量標識為添加增量和刪除增量中的至少一個增量。
19.根據權利要求17的機器可讀存儲器，還包括將所述至少第一增量標識為更改增量和移動增量中的至少一個增量。
20.根據權利要求12的機器可讀存儲器，還包括在所述有選擇地接受增量的步驟之前，檢測至少兩個增量之間的衝突；以及提供所述衝突的通知。
全文摘要
一種在軟體開發過程期間合併電子文檔的多個不同版本的方法，所述方法可以包括標識所述電子文檔的所述多個不同版本。所述電子文檔可以具有定義的結構。所述方法還可以包括確定所述不同版本之間的多個增量和根據所述電子文檔的所述定義的結構來確定所述多個增量中的單個增量之間的關係。根據所述確定的關係，所述多個增量中的一個或多個增量可以在合併後的電子文檔中被有選擇地接受。
文檔編號G06F9/44GK1783093SQ20051012919
公開日2006年6月7日 申請日期2005年11月14日 優先權日2004年12月1日
發明者S·科旺, M·穆斯塔法, F·普蘭特 申請人:國際商業機器公司