paulwong

在 Rational Team Concert 中多個 stream 代碼同步的方法

stream 簡介

Stream（流）是 Jazz 源代碼管理系統(tǒng)中的重要成員，體現(xiàn)項目開發(fā)中的一個版本，由一個或者多個 component（ 組件）構成。流的建立使得團隊成員在不同的版本之間進行代碼的共享與管理，滿足項目迭代開發(fā)中代碼管理的需要，促進團隊成員之間更好的協(xié)作。組件是代碼共享與管理的基本單位，由一個文件或者文件夾所構成，團隊成員可以通過使用流中的組件進行代碼的共享。

多個 stream 的應用場景

目前，軟件開發(fā)中迭代開發(fā)非常普遍，項目的開發(fā)經(jīng)常涉及兩個或多個版本。即在一個版本尚未發(fā)布就需要進入下一個軟件版本的開發(fā)，這樣使得項目開發(fā)人員需要同時維護多個軟件版本。特別是一個缺陷需要在多個版本上解決，這樣在這些不同的軟件版本上進行代碼同步就成為團隊開發(fā)人員日常的工作內(nèi)容。如何簡化代碼同步的流程，提高多個軟件版本代碼同步的效率以及減少在多個軟件版本中由于代碼同步引起的缺陷數(shù)，對于降低軟件開發(fā)成本和提高軟件質(zhì)量具有重要的意義。

RTC 對多 stream 代碼同步的支持

源代碼管理與共享是項目開發(fā)中的重要內(nèi)容，而 RTC 作為主流的源代碼管理工具，對項目的源代碼的管理與共享提供了很好的機制。在實際的項目開發(fā)過程中，項目擁有者需要在遠程 Jazz 服務器上創(chuàng)建 stream，項目開發(fā)人員在遠程 Jazz 服務器上基于此 stream 創(chuàng)建自己的版本庫工作空間。除此之外，開發(fā)人員還需要在本地的機器上創(chuàng)建自己的本地工作空間。開發(fā)人員通過 Check-in 操作將本地工作空間的改動同步到遠程 Jazz 服務器上的自己的版本庫工作空間，通過 Deliver 操作將遠程版本庫工作空間的代碼同步到團隊共享的 stream 上。其他團隊人員則通過 Accept 操作將代碼從 stream 同步到自己遠程的版本庫工作空間，并通過 Load 操作將版本庫工作空間的源代碼下載到本地的工作空間。依此類推，RTC 就可以同時管理多個 stream 并進行有效的共享，其具體的源代碼管理與共享機制如圖 1 所示：

通過 RTC 中對源代碼的管理與共享機制可以看出，如果不進行任何修改與配置，在多個 stream 上，開發(fā)人員只能通過單獨維護每個 stream 上的源代碼，并在這些 stream 上進行代碼的來回復制達到多 stream 上的源代碼同步，這樣無疑增加了維護和同步多個 stream 上的源代碼成本。事實上 RTC 可以通過更改相應的 flow target（目標流指向）來簡化多 stream 上的源代碼同步，有效的提高項目開發(fā)的效率。

總的來說，RTC 對多 stream 上源代碼的同步提供了三種方式：各 stream 單獨同步，stream 由低版本向高版本同步及 stream 由高版本向低版本同步，具體操作如下圖所示（圖中以兩個 stream 為例，多個 stream 可以依此進行類推）：

從圖 2 可以看出，同步 stream1 和 stream2 上的源代碼需要在每個 Local workspace 上 Check-in 相應的代碼，在同步第二個 stream 時需要從一個 Local workspace 上拷貝源代碼到另一個 Local workspace 上，這樣加大了開發(fā)人員的工作量，并且增加了一些由拷貝源代碼所造成的缺陷。圖 3 與圖 4 的同步機制沒有多大差別，圖 3 所示的為源代碼從低版本（stream1）向高版本（stream2）同步，開發(fā)人員先將代碼提交到 stream1，然后改變 stream2 的目標流指向，接受之前提交到 stream1 上的變更集，最后通過 Jazz Server 上的 Repository workspace 將變更集提交到 stream2 上。圖 4 所示為源代碼從高版本（stream2）低高版本（stream1）同步，具體過程與低版本（stream1）向高版本（stream2）同步相反。由于高版本往往會包含低版本沒有實現(xiàn)的功能，所以對于多 stream 的源代碼同步，采用從低版本向高版本同步的方式遇到的潛在的源代碼沖突相對較少，開發(fā)人員解決這些沖突并合并變更集所付出的成本也隨之降低。因此，在實際項目開發(fā)中，對于多 stream 的源代碼同步，采用低版本（stream1）向高版本（stream2）同步的方式最佳。

RTC 中多 stream 代碼同步的示例

由于多 stream 從低版本中向高版本同步時潛在的沖突最少，因此本文將以這種同步方式作為示例說明如何在兩個 stream 實現(xiàn)源代碼的同步。對于三個或三個以上 stream 的代碼同步，讀者可以依此類推。在示例中，我們擁有兩個 stream，6.3.1.1 和 6.3.2。并且我們已經(jīng)創(chuàng)建好兩個 stream 上對應的兩個我們自己的版本庫工作空間。

無代碼沖突情況下的代碼同步

打開 Pending Changes 視圖，在 6.3.1.1 版本庫工作空間上有個新的可交付變更集，右擊選擇 deliver 對其進行交付，具體操作如圖 5 所示：

打開更新版本的 6.3.2 版本庫工作空間，更改其 Flow Targets 到 6.3.1.1 stream。如圖 6 所示，將 6.3.1.1 stream 置成當前 flow target 且是默認 flow target，然后確認保存。

保存后結果如圖 7 所示。

如圖 8 所示，此時再次查看 Pending Changes，6.3.2 版本庫工作空間已經(jīng)指向 6.3.1.1 stream，剛才在 6.3.1.1 版本庫工作空間中交付的變更集出現(xiàn)在 6.3.2 版本庫工作空間的可接受變更集中。此時該變更集與 6.3.2 版本庫工作空間中代碼不存在沖突，可以直接選擇接受。

接受后，將 6.3.2 版本庫工作空間的 flow target 改回 6.3.2 stream ，如圖 9 所示：

從圖 10 中可以看出，在 Pending Changes 中，6.3.2 版本庫工作空間中有了新的可交付變更集，該變更集正是 6.3.1.1 版本庫工作空間之前交付的變更集。由于不存在沖突，我們可以直接將該變更集交付到 6.3.2 stream 中，從而實現(xiàn)兩個 stream 上針對該變更集的源代碼同步。在下一節(jié)中我們將給出存在代碼沖突的同步示例，為了模擬這種情況，我們暫且不交付此變更集。

有代碼沖突情況下的代碼同步

同樣，打開 Pending Changes 視圖，在 6.3.1.1 版本庫工作空間提交一個新的變更集模擬代碼沖突，右擊選擇 deliver 對其進行交付，具體操作如圖 11 所示：

更改 6.3.2 版本庫工作空間 flow target 到 6.3.1.1 stream。從 Pending Changes 視圖中可以看到 6.3.1.1 版本庫工作空間中新提交的變更集。該變更集前出現(xiàn)橙色高亮，說明該變更集和 6.3.2 版本庫工作空間中可交付的變更集存在代碼沖突。具體操作如圖 12 所示：

選擇接受該變更集，此時會彈出是否自動解決沖突的對話框如圖 13，我們這里建議選擇 Resolve Later，以防止出現(xiàn)代碼合并錯誤的情況發(fā)生。下面我會給出具體的情況說明在接受沖突變更集后如何 Resolve。Resolve 有兩種方法：自動合并和手動合并。什么時候選擇自動合并，什么時候需要手動合并，這對于維護代碼的同步和準確性十分重要。

選擇 Resolve Later 后，將 6.3.2 版本庫工作空間的 flow target 改回 6.3.2 stream。如圖 14 所示，出現(xiàn)未解決代碼沖突。雙擊打開沖突比較視圖。

如果視圖中僅有藍色標識，說明沒有嚴重沖突。如圖 15 所示，可以選擇 Auto Merge 自動合并代碼。

圖 15 大圖

如果視圖中有紅色標識，說明存在嚴重沖突，自動合并代碼將導致代碼錯亂。如圖 16 所示，將紅色部分右側代碼拷貝覆蓋到左側，手工完成覆蓋后，選擇 Resolve As Merge 完成合并。

圖 16 大圖

在彈出的對話框中選擇 OK 確定手動合并操作，如圖 17 所示：

這樣合并完成后，6.3.2 版本庫工作空間可交付變更集如圖 18 所示。此時可看到被合并的原變更集后出現(xiàn) 1 merged 字樣，合并操作完成。對其交付后，6.3.1.1 stream 和 6.3.2 stream 在該變更集存在沖突的情況下實現(xiàn)了代碼同步。

撤銷已交付的錯誤代碼

在同步兩個或多個 stream 的時候，很可能誤將不屬于本 stream 的代碼 deliver 到 stream 上。如果錯誤交付的代碼過多的話，手動去刪除錯誤交付的代碼將會需要花費很大的工作量來將代碼還原到原來的狀態(tài)。而且，還會帶來代碼被錯誤修改的風險。而 RTC 提供了一種回退（Reverse）的功能，將錯誤交付的代碼自動清除掉，并恢復到原來的狀態(tài)。

回退（Reverse）功能的具體操作步驟如下：

1. 右擊錯誤提交的代碼所相關的 work iteam，并單擊彈出的 Reverse 菜單。

2. 點擊 Reverse 菜單后，會彈出如下圖 20 所示的窗口，指示修改前的文件將會在 Pending Patches 以 patch 的形式顯示出來。然后，點擊 OK 按鈕。

3. 如圖 21 所示，在 patch 中你可以通過雙擊 java 文件來查看原來文件里的內(nèi)容和錯誤交付代碼后的文件的差異，來查看是否是你想要恢復的結果。

4. 將這個 patch 添加到現(xiàn)有的 workspace 上面，從而將原有的變更集先恢復到本地的 workspace 上。

5. 原有的文件將會作為未提交的文件顯示出來。

6. 通過將原有的代碼重新 check-in 和 deliver，從而將被錯誤修改的代碼從項目組共享的 stream 上刪除出去。

如果將代碼錯誤提交到 stream 后，有其他開發(fā)人員提交了自己的代碼，這個時候要進行回退的時候，需要查看需要回退的文件是否和其他開發(fā)人員修改的文件有沖突。如果有沖突，可以通過前面提過的方法進行代碼沖突的整合；或者把錯誤提交代碼以后其他開發(fā)人員提交的代碼先回退回去，在把錯誤提交的代碼從 stream 上刪除以后，重新將其他開發(fā)人員提交的代碼 deliver 到 stream 上。

致謝

衷心的感謝錢巧能工程師在本文大綱方面的討論所提供的意見和支持。

結束語

本文詳細介紹了 RTC 代碼同步的原理，并且比較了目前 RTC 中多 stream 上代碼同步的幾種方法，最后以具體示例說明了如何在 RTC 中進行多 stream 的代碼同步，解決代碼同步中出現(xiàn)的沖突及如何撤銷錯誤的代碼同步。讀者可以通過閱讀本文，掌握各種在 RTC 中多 stream 代碼同步的方法，并根據(jù)項目實際情況選擇，靈活運用，提高項目開發(fā)的整體效率。

posted on 2012-10-31 21:36 paulwong 閱讀(975) 評論(0)  編輯  收藏 所屬分類: Configuration Management