管理從ClearCase到SVN的轉變

Question

我負責從工作中的ClearCase轉到SVN，我正在尋找幫助爲團隊定義合適的工作流程。我們在一個非常龐大的代碼庫上工作，大約有50名開發人員在3個不同的站點工作。我是專門負責回購的團隊的一員。我們不是開發人員，但我們的工作是合併未來版本的開發包。我們都不熟悉svn。

我們對ClearCase的當前工作流：

1. dev目錄中創建一個專用的brtype（將被實例化的每次結帳元素）
2. dev目錄中創建指向在最新版本的視圖「主」在他的分支
3. 分支
4. 開發代碼，並檢查他的變化每月一次assmebly小組（US）創建brtype +裝配圖
5. 我們認爲：合併，編譯，發佈
6. 一旦它的發佈，合併主枝
7. 重複

在SVN，我們就無法做到這一點。我主要關心的是磁盤空間。 如果每個開發者爲他的開發者創建一個分支，那麼我們在一週左右就會耗盡空間。

SVN工作流程（方案）

我想到了用 '打補丁' 的命令（我們在Unix主持工作）。

1. 開發檢出（只讀）主幹
2. 代碼。生成一個補丁。將其發送給組裝團隊。

3. Assembly team co。應用補丁。檢查英寸

4. 重複

我的問題是，這是一個合理的工作流程？如果我們可以用什麼工具來：

• 提供的補丁（一些補丁成爲實際開發時間後釋放許多個月的部分）
• 合併衝突？

我應該強調，我對回購本身的遷移不感興趣。它已經被照顧，並有據可查。我的問題是......我們從哪裏出發？

Answer 1

你可以看到一個（舊，但仍然相關）的differences between ClearCase and SVN

救命之恩IBM的文章是「複製」是一個非常便宜的快捷操作，讓你可以創建一個分支或基準/標籤在不變的短時間內，無論你影響多少元素。

將此與CC進行比較，其中創建分支實際上是零時間操作（感謝配置規範中管理的延遲分支），但正常的基準策略是標記每個元素的昂貴操作 - 但是在哪裏可以看到任何目錄或文件的完整版本樹。

因此，您的原始工作流程仍然存在，您只需要小心合併到trunk即可。
請參閱Advanced merging（使用最新的SVN 1.7），您需要svn merge --reintegrate。

Answer 2

在SVN下，我們無法做到這一點。我主要關心的是磁盤空間。如果每個開發者爲他的開發人員創建一個分支，那麼我們在一週左右就會耗盡空間。

SVN中的副本很便宜，因爲只存儲差異。你的補丁會有相同的磁盤影響。您可以輕鬆地工作到清晰的工作流程。