stream 簡介
Stream（流）是 Jazz 源代碼管理系統中的重要成員，體現項目開發中的一個版本，由一個或者多個 component（ 組件）構成。流的建立使得團隊成員在不同的版本之間進行代碼的共享與管理，滿足項目迭代開發中代碼管理的需要，促進團隊成員之間更好的協作。組件是代碼共享與管理的基本單位，由一個文件或者文件夾所構成，團隊成員可以通過使用流中的組件進行代碼的共享。
多個 stream 的應用場景
目前，軟件開發中迭代開發非常普遍，項目的開發經常涉及兩個或多個版本。即在一個版本尚未發布就需要進入下一個軟件版本的開發，這樣使得項目開發人員需要同時維護多個軟件版本。特別是一個缺陷需要在多個版本上解決，這樣在這些不同的軟件版本上進行代碼同步就成為團隊開發人員日常的工作內容。如何簡化代碼同步的流程，提高多個軟件版本代碼同步的效率以及減少在多個軟件版本中由于代碼同步引起的缺陷數，對于降低軟件開發成本和提高軟件質量具有重要的意義。
RTC 對多 stream 代碼同步的支持
源代碼管理與共享是項目開發中的重要內容，而 RTC 作為主流的源代碼管理工具，對項目的源代碼的管理與共享提供了很好的機制。在實際的項目開發過程中，項目擁有者需要在遠程 Jazz 服務器上創建 stream，項目開發人員在遠程 Jazz 服務器上基于此 stream 創建自己的版本庫工作空間。除此之外，開發人員還需要在本地的機器上創建自己的本地工作空間。開發人員通過 Check-in 操作將本地工作空間的改動同步到遠程 Jazz 服務器上的自己的版本庫工作空間，通過 Deliver 操作將遠程版本庫工作空間的代碼同步到團隊共享的 stream 上。其他團隊人員則通過 Accept 操作將代碼從 stream 同步到自己遠程的版本庫工作空間，并通過 Load 操作將版本庫工作空間的源代碼下載到本地的工作空間。依此類推，RTC 就可以同時管理多個 stream 并進行有效的共享，其具體的源代碼管理與共享機制如圖 1 所示：
圖 1. RTC 中多 stream 源代碼管理與共享機制
通過 RTC 中對源代碼的管理與共享機制可以看出，如果不進行任何修改與配置，在多個 stream 上，開發人員只能通過單獨維護每個 stream 上的源代碼，并在這些 stream 上進行代碼的來回復制達到多 stream 上的源代碼同步，這樣無疑增加了維護和同步多個 stream 上的源代碼成本。事實上 RTC 可以通過更改相應的 flow target（目標流指向）來簡化多 stream 上的源代碼同步，有效的提高項目開發的效率。
總的來說，RTC 對多 stream 上源代碼的同步提供了三種方式：各 stream 單獨同步，stream 由低版本向高版本同步及 stream 由高版本向低版本同步，具體操作如下圖所示（圖中以兩個 stream 為例，多個 stream 可以依此進行類推）：
圖 2. 各 stream 單獨同步
圖 3. stream 由低版本向高版本同步
圖 4. stream 由高版本向低版本同步
從圖 2 可以看出，同步 stream1 和 stream2 上的源代碼需要在每個 Local workspace 上 Check-in 相應的代碼，在同步第二個 stream 時需要從一個 Local workspace 上拷貝源代碼到另一個 Local workspace 上，這樣加大了開發人員的工作量，并且增加了一些由拷貝源代碼所造成的缺陷。圖 3 與圖 4 的同步機制沒有多大差別，圖 3 所示的為源代碼從低版本（stream1）向高版本（stream2）同步，開發人員先將代碼提交到 stream1，然后改變 stream2 的目標流指向，接受之前提交到 stream1 上的變更集，最后通過 Jazz Server 上的 Repository workspace 將變更集提交到 stream2 上。圖 4 所示為源代碼從高版本（stream2）低高版本（stream1）同步，具體過程與低版本（stream1）向高版本（stream2）同步相反。由于高版本往往會包含低版本沒有實現的功能，所以對于多 stream 的源代碼同步，采用從低版本向高版本同步的方式遇到的潛在的源代碼沖突相對較少，開發人員解決這些沖突并合并變更集所付出的成本也隨之降低。因此，在實際項目開發中，對于多 stream 的源代碼同步，采用低版本（stream1）向高版本（stream2）同步的方式最佳。
RTC 中多 stream 代碼同步的示例
由于多 stream 從低版本中向高版本同步時潛在的沖突最少，因此本文將以這種同步方式作為示例說明如何在兩個 stream 實現源代碼的同步。對于三個或三個以上 stream 的代碼同步，讀者可以依此類推。在示例中，我們擁有兩個 stream，6.3.1.1 和 6.3.2。并且我們已經創建好兩個 stream 上對應的兩個我們自己的版本庫工作空間。
無代碼沖突情況下的代碼同步
打開 Pending Changes 視圖，在 6.3.1.1 版本庫工作空間上有個新的可交付變更集，右擊選擇 deliver 對其進行交付，具體操作如圖 5 所示：
圖 5. 交付變更集界面
打開更新版本的 6.3.2 版本庫工作空間，更改其 Flow Targets 到 6.3.1.1 stream。如圖 6 所示，將 6.3.1.1 stream 置成當前 flow target 且是默認 flow target，然后確認保存。
圖 6. 版本庫工作空間界面
保存后結果如圖 7 所示。
圖 7. 更改 Flow Target 界面
如圖 8 所示，此時再次查看 Pending Changes，6.3.2 版本庫工作空間已經指向 6.3.1.1 stream，剛才在 6.3.1.1 版本庫工作空間中交付的變更集出現在 6.3.2 版本庫工作空間的可接受變更集中。此時該變更集與 6.3.2 版本庫工作空間中代碼不存在沖突，可以直接選擇接受。
圖 8. 接受 Incoming 變更集界面
接受后，將 6.3.2 版本庫工作空間的 flow target 改回 6.3.2 stream ，如圖 9 所示：
圖 9. FlowTarget 配置界面
從圖 10 中可以看出，在 Pending Changes 中，6.3.2 版本庫工作空間中有了新的可交付變更集，該變更集正是 6.3.1.1 版本庫工作空間之前交付的變更集。由于不存在沖突，我們可以直接將該變更集交付到 6.3.2 stream 中，從而實現兩個 stream 上針對該變更集的源代碼同步。在下一節中我們將給出存在代碼沖突的同步示例，為了模擬這種情況，我們暫且不交付此變更集。
圖 10. 交付 Outgoing 變更集界面
有代碼沖突情況下的代碼同步
同樣，打開 Pending Changes 視圖，在 6.3.1.1 版本庫工作空間提交一個新的變更集模擬代碼沖突，右擊選擇 deliver 對其進行交付，具體操作如圖 11 所示：
圖 11. 交付 Outgoing 變更集界面
更改 6.3.2 版本庫工作空間 flow target 到 6.3.1.1 stream。從 Pending Changes 視圖中可以看到 6.3.1.1 版本庫工作空間中新提交的變更集。該變更集前出現橙色高亮，說明該變更集和 6.3.2 版本庫工作空間中可交付的變更集存在代碼沖突。具體操作如圖 12 所示：
圖 12. 接受 Incoming 變更集界面
選擇接受該變更集，此時會彈出是否自動解決沖突的對話框如圖 13，我們這里建議選擇 Resolve Later，以防止出現代碼合并錯誤的情況發生。下面我會給出具體的情況說明在接受沖突變更集后如何 Resolve。Resolve 有兩種方法：自動合并和手動合并。什么時候選擇自動合并，什么時候需要手動合并，這對于維護代碼的同步和準確性十分重要。
圖 13. 沖突提示界面
選擇 Resolve Later 后，將 6.3.2 版本庫工作空間的 flow target 改回 6.3.2 stream。如圖 14 所示，出現未解決代碼沖突。雙擊打開沖突比較視圖。
圖 14. 未解決沖突界面
如果視圖中僅有藍色標識，說明沒有嚴重沖突。如圖 15 所示，可以選擇 Auto Merge 自動合并代碼。
圖 15. 自動解決沖突操作
圖 15 大圖
如果視圖中有紅色標識，說明存在嚴重沖突，自動合并代碼將導致代碼錯亂。如圖 16 所示，將紅色部分右側代碼拷貝覆蓋到左側，手工完成覆蓋后，選擇 Resolve As Merge 完成合并。
圖 16. 手動解決沖突界面
圖 16 大圖
在彈出的對話框中選擇 OK 確定手動合并操作，如圖 17 所示：
圖 17. 手動解決沖突確認界面
這樣合并完成后，6.3.2 版本庫工作空間可交付變更集如圖 18 所示。此時可看到被合并的原變更集后出現 1 merged 字樣，合并操作完成。對其交付后，6.3.1.1 stream 和 6.3.2 stream 在該變更集存在沖突的情況下實現了代碼同步。
圖 18. 交付合并后變更集界面
撤銷已交付的錯誤代碼
在同步兩個或多個 stream 的時候，很可能誤將不屬于本 stream 的代碼 deliver 到 stream 上。如果錯誤交付的代碼過多的話，手動去刪除錯誤交付的代碼將會需要花費很大的工作量來將代碼還原到原來的狀態。而且，還會帶來代碼被錯誤修改的風險。而 RTC 提供了一種回退（Reverse）的功能，將錯誤交付的代碼自動清除掉，并恢復到原來的狀態。
回退（Reverse）功能的具體操作步驟如下：
- 右擊錯誤提交的代碼所相關的 work iteam，并單擊彈出的 Reverse 菜單。
圖 19. work iteam 的回退
- 點擊 Reverse 菜單后，會彈出如下圖 20 所示的窗口，指示修改前的文件將會在 Pending Patches 以 patch 的形式顯示出來。然后，點擊 OK 按鈕。
圖 20. 添加到 Pending Changes
- 如圖 21 所示，在 patch 中你可以通過雙擊 java 文件來查看原來文件里的內容和錯誤交付代碼后的文件的差異，來查看是否是你想要恢復的結果。
圖 21. Patch 顯示界面
- 將這個 patch 添加到現有的 workspace 上面，從而將原有的變更集先恢復到本地的 workspace 上。
圖 22. 合并 Patch 界面
- 原有的文件將會作為未提交的文件顯示出來。
圖 23. 未解決沖突界面
- 通過將原有的代碼重新 check-in 和 deliver，從而將被錯誤修改的代碼從項目組共享的 stream 上刪除出去。
圖 24. Check-in 變更集界面
如果將代碼錯誤提交到 stream 后，有其他開發人員提交了自己的代碼，這個時候要進行回退的時候，需要查看需要回退的文件是否和其他開發人員修改的文件有沖突。如果有沖突，可以通過前面提過的方法進行代碼沖突的整合；或者把錯誤提交代碼以后其他開發人員提交的代碼先回退回去，在把錯誤提交的代碼從 stream 上刪除以后，重新將其他開發人員提交的代碼 deliver 到 stream 上。
致謝
衷心的感謝錢巧能工程師在本文大綱方面的討論所提供的意見和支持。
結束語
本文詳細介紹了 RTC 代碼同步的原理，并且比較了目前 RTC 中多 stream 上代碼同步的幾種方法，最后以具體示例說明了如何在 RTC 中進行多 stream 的代碼同步，解決代碼同步中出現的沖突及如何撤銷錯誤的代碼同步。讀者可以通過閱讀本文，掌握各種在 RTC 中多 stream 代碼同步的方法，并根據項目實際情況選擇，靈活運用，提高項目開發的整體效率。