將Clearcase遷移到X

Question

我被要求選擇Clearcase-UCM的開源替代方案，並且我需要一個建議什麼是最佳匹配。以下給出了我收集的一些參數：

• 一半的開發團隊使用集成視圖，開發視圖，重定位和交付方法。其餘的只是直接在私有視圖的集成流上工作，就好像它是主幹一樣。
• 所有團隊都使用標準版本的基線。
• 他們聲稱將面臨Clearcase-UCM的合併問題，因此替代方案必須具有精心設計的合併功能。
• 零維護 - 該工具沒有VCS管理員。
• 基於Windows的開發，所以該工具必須具備良好的win32支持。
• IDE集成（eclipse）。
• Mac-OS支持。
• 很好有：遷移工具。

什麼工具適合這兩種工作方法（兩組都不會採用其他方法）？ 我有svn，mercurial和git作爲替代到目前爲止。他們中的一個會合適嗎？還有其他的選擇嗎？

Answer 1

我不能爲遷移工具發言，但mercurial已經爲我們工作得很好。我們有WinXP，Mac OS X和Linux人員的組合，並沒有出現任何障礙。我沒有使用IDE，但我相信Aptana收購了pydev組（Python for Python），所以如果他們有這些，我不會感到驚訝。

Answer 2

WHE使用UCM和創建基線，則有效地識別預定義的子組的存儲庫中的一個版本（一個VOB內定義的UCM組件，除非你有定義一個所有VOB的作爲組分）

因此，如果您使用SVN，Git或Mercurial，則必須意識到您的每個UCM組件實際上都將是一個（SVN-Git或Mercurial）存儲庫。

此外，您將需要重新創建UCM依賴的概念

的最接近的原則在此SO answer描述（「編輯基線依賴關係」，其中沒有這些工具都有。）：這是可以做到但仍然是手動的。

注： 「零維護 - 沒有爲工具沒有VCS管理員。」 ...... errr好運與一個：

• 備份
• DRP（災難恢復計劃）
• 權訪問某些具有「敏感」內容的存儲庫
• 某些操作的腳本和客戶端封裝
• ....

沒有母校，你會選擇什麼工具，你將需要一個管理員（不是全職，但還是蠻參與管理任務）

---

關於「tracability」，主要是通過在活動代表UCM，但也可以通過流層次結構來定義合併工作流程，但在Git/Mercurial中不能很好地轉換：這些工具是不同的。

對於Git，一個提交是一個活動最接近的事情，尤其是因爲'git rebase -i'（重定向交互）允許您重新定義提交的內容（有點像當您再次選擇新的結帳活動時）
關於合併，由於它們在Git或Mercurial中非常容易，因此沒有真正的「合併工作流」通過交付/重新定義操作正式定義。
當用戶認爲合適時，創建並使用/合併私有分支，其中一些分支被髮布到另一個外部存儲庫。

Answer 3

在某種程度上，技術部分是易於處理的部分 - 您可以在MacOSX中使用它，或者您無法使用它。棘手的部分是作爲CC許可證的一部分購買的「服務」而這些對開發者來說並不明顯，開發者也不一定會關心。

貴公司的資產將坐落在由您選擇的工具管理的存儲庫中，從一個工具移到另一個工具並不總是那麼容易。所以，很大程度上取決於您的產品的生命週期。它們在市場上銷售6個月，6年甚至更長時間嗎？這些工具中的一些問題只存在幾年，並且在某種程度上受時尚影響。 Git贊成，Bazaar似乎已經失寵。

我的建議是查看Rational根據您當前的安排提供的內容，並嘗試找到服務提供商支持的工具，該工具將爲您提供同等服務。然後比較成本。

您可能還想考慮如何讓您的開發人員脫離ClearCase並使用新工具。根據我的經驗，遷移工具對於人來說是80％。他們現在可能會痛苦地呻吟，但如果零維修方案中的新工具不太好，那麼他們的觀點可能會改變...在那裏。

如果它們在合併時遇到問題，則不能保證轉到其他工具可以解決問題。如果遷移後問題仍然存在，您將會知道這不是問題的工具。

任何工具都可以是零維護。它會中斷，你不會修復它，並遷移到另一個'本月的工具'。