我已經爲我的發佈應用了完整基準。對於前。基線「MYProj_2.0.0.20」。Clearcase UCM中完整基線和增量基線之間的區別是什麼？
然後測試團隊發現一些重大問題。爲了解決這個問題，開發團隊已經做了一些改變
完成建設後，我再次施加相同的基線「MYProj_2.0.0.20。但這次我已經申請增量基線。按照UCM，基線MYProj_2.0.0.20被拒絕作爲MYProj_2.0.0。 20.3452（一些隨機數在結尾使其唯一）
現在，如果我認爲MYProj_2.0.0.20.3452作爲發佈基準，它將包含所有更改還是僅包含更改（「MYProj_2.0.0.20 「和 」MYProj_2.0.0.20.3452「）。
請澄清我。
它將包含所有更改。
除了一個增量基線將通過增加計算這些變化：
請參閱「Types of baselines」：
- 一個全基線是你通過記錄組件根目錄下的所有元素的所有版本創建一個基線。
- 增量基線是通過記錄上一個完整基線以及自上次完整基線創建以來發生更改的元素版本創建的基準。
（也有「關卡基本線」，如「about ClearCase baselines」詳細介紹，通過交付和變基操作自動創建的，但你並不需要將現在與右關注）
這就是爲什麼我總是更喜歡一個完整的基線：如果您的上一個基線是完整基線，所有的增量操作（如「與另一個基線比較」）更快。
支持增量基線的觀點是它們創建速度更快（因爲版本的基線數量較少）。
但是如果你的UCM組件是這麼大的，把標籤放在全部它的版本太長，可能你的組件太大了。
請注意，您始終可以將增量基準升級到完整基準。
還要注意的是，你有之間的差異：
MYProj_2.0.0.20‘：你可以把儘可能多的’MYProj_2.0.0.20」基線，只要你想）MYProj_2.0.0.20」已被使用，那麼ClearCase的產生在最後一些數字：「MYProj_2.0.0.20.345 2」）
有利於增量baselines-的還有一點很明顯，他們往往佔據更少的空間會見ADATA。因此，在大型開發項目（因此包含巨大的UCM組件）和5年以上的日常基線+構建的情況下，這在管理VOB大小方面發生了巨大變化。 – 2012-03-20 04:03:21
@PulakAgrawal每當我面對這樣的問題時，我立即將那個巨大的組件的一部分提取到一個新的組件中。 「巨大」的組件打敗了UCM組件的目的，即定義一組連貫的文件：它的大小必須被包含和合理。 – VonC 2012-03-20 06:46:03
@PulakAgrawal據說，您的評論說明了ClearCase的一個主要流程。它。請問。不。規模。 – VonC 2012-03-20 06:46:32