UCM Clear Case：一個項目中的流對象與多個項目的對比

Question

我們有一個項目，並且即將添加一個新的功能塊到其他穩定的代碼庫，除了修復缺陷之外，沒有任何重大更改。該計劃不是單獨開發新功能一段時間（可能是一個月）進行中間構建和測試，並且功能已完成且質量可接受將新功能的代碼合併到主分支中。

的問題是以下兩種情況下，什麼是在清除案例方面更好：

1. 創建基於當前項目的集成流基準中的新項目，開發新功能這個單獨的項目將中間交付給新項目的整合流，並從整合流中進行構建。並最終將新項目的集成流中的更改傳遞到主項目（到dev或int）。

2. 在主項目中使用流的層次結構：在主項目中創建一個集成流的子流（讓它稱爲temp_int）和一個temp_int的子流（讓它稱爲temp_dev）。在temp_dev中開發新功能，定期交付給temp_int並從temp_int構建，然後將新功能從temp_int交付到主集成流。

Answer 1

您是否需要創建新項目或創建子流是一個經典問題。

在我看來，兩種選擇都相當。

唯一顯著差異是基礎基線，你將能夠爲這個特殊的發展努力創造新的流時挑：

• 爲子流，你只能選擇一個基準在父流上生成。
• 對於新項目的主流，您將能夠選擇任何您想要的基線。

比其他：

• 一個新的項目提供一個連貫的容器隔離幾個流了新的空間。但是，如果您需要在新功能開發期間對穩定代碼進行一些小的改進，那麼交付將會按順序進行。
• 子流允許在開發完成後清晰地顯示最終客戶端：交付將是合併到父流的自然操作。此外，可以從母流向您的開發流定期重新分配數據，以保持最新狀態。

因此，如果您只有一個流清晰地交付製作，子流選項就足夠了。
如果你的開發變得比預想更復雜，那麼一個項目會更好。