上篇文章中的連結搞錯，

clearcase的實施方案 ，Base的。其實就是較多的使用分支和標籤兩種策略

用來初步明白Base專案差不多。深入的還需要看更多的資料

先講下UCM的發展歷史，1999就提出了，然後到現在已經10多年了。所以算是相當成熟了，IBM官方出了一些文章講述UCM，介紹的非常好。 好文章1

看下概念：（黑色下劃線粗體是UCM特有的）

UCM ： Unified Changed Management 的縮寫 ，統一變更管理模式，如果Base是靈活的自動相機，UCM就是手動一體化相機，因為已經非常整合。UCM通過抽象層次的提升簡化了軟體開發，從而使得軟體開發團隊從更高的層次根據活動（activity）來管理變更。通過UCM，一個開發活動可以自動地同其變更集（封裝了所有用於實現該活動的專案工件）相關聯，這樣避免了管理人員手動跟蹤所有檔案變更。

VOB ，全稱：version object base，版本物件庫。UCM這裡分兩種VOB，component VOB和PVOB

Project VOB(PVOB)（新增） ： 是儲存 UCM 所需要的一些特殊的資訊，如 Proejcts ， Stream ， Activity 及 Change Sets 等，一個 PVOB 可以包含多個 Project 的資訊， Project 的資訊必須儲存在 PVOB 中。實際專案的資料也可以放在PVOB中。不過不推薦，一般放在component VOB。

view,檢視 ，有個形象的比喻，。大家熟悉相機，通過調節相機的鏡頭（view）來觀察事物，類似Clearcase也是通過view來觀察和操作VOB中的內容，view通過某些規則來獲取VOB中元素的某個版本，並組成了作業系統中的目錄結構。view其實是“開發者的工作空間”，

view的config spec ，config spec就是上面說的特定的規則，可以抽象比喻成“濾鏡”。他可以幫我們選擇vob中的某個元素的特定版本來供我們觀察和操作。UCM裡面config spec根據stream的配置自動生成，不需要手工干預。

Project （新增） ： 是 ClearCase UCM 的一個概念，包含了配置管理所需要的一些配置資訊，如果 Component 、 Baseline ， Stream 等，每個 Project 都有一個 Integration Stream 。
project是基於compoent創建出來的

ntegration Stream

在一個專案的幹流上（UCM稱之為整合流）可以拉出很多的子流，這些子流根據不同的需要安排不同的人員在上面開發。（如此看來stream和base模式的branch作用一樣的），每個子流開發到一定程度以後可以把子流上的開發成果提交到整合流上去，在整合流上整合管理員根據提交的內容進行編譯，測試以後在整合流上打上基線（baseline），等所有的測試通過以後可以推薦基線，

Development Stream （新增） ： UCM的概念，可以理解為一個獨立的開發環境，包含了在這個開發流上的 Activity 與修改的配置項的版本， UCM 通過開發流簡化了並行開發的配置管理工作。  

Activity （新增） ： Activity是 ClearCase UCM 模式中的一個概念，通過變更集 (Change Set) 跟蹤完成一項開發任務所引起的所有配置項的變更。在 UCM 模式下所有的 Check Out 、 Check In 、 Add to Source Control 等引起配置項發生變化的操作必須關聯到一個 Activity 。

 update：2010-07-08：活動，也就是專案中的任務，賦予一組修改以一個明確的理由，包含一組change set。通俗講應該是專案裡面只要發生了變化（產生變更集），就必須給個理由。也就是關聯個activity

update：2010-07-22：摘自CCRC7.0IDE外掛中文幫助文件

活動
在 ClearCase UCM 檢視中，您在任何時候要向源控制新增資源或修改已經處於源控制之下的資源，都必須將操作與某個 UCM 活動相關聯 ，從而確定在特定開發任務期間建立的一組版本。當對 Rational ClearQuest® 啟用 UCM 專案時，將建立活動並在 Rational ClearQuest 資料庫中作為記錄對其進行維護。當未對 Rational ClearQuest 啟用 UCM 專案時，將建立活動並在 ClearCase 專案 VOB 中作為元資料對其進行維護。

每個活動都包含標題、活動標識和變更集。標題是一個文字字串，活動標識是一個由 ClearQuest 或 ClearCase 生成的唯一標識，而變更集指定在處理活動時修改（或新增到源控制）的每個檔案的一個版本。

當您建立新活動或選擇現有活動來與某個操作關聯時，該活動就成為您正在工作的 ClearCase 檢視的當前活動。每個 ClearCase UCM 檢視可以具有的當前活動不能超過一個。

雖然 UCM 專案經理通常制定用來幫助使用者向活動分配工作的準則，但是活動並不限於特定的工作範圍。例如，專案經理可能決定由您在修正缺陷或新增新功能部件時建立的版本來構成一個活動。活動還可以包含將應用程式移植到新的作業系統或硬體平臺所需的所有更改。

您可以使用 ClearCase 元資料瀏覽器導航器來檢視 UCM 檢視中的活動。

Component（新增） ： 可以理解為一些程式碼、文件、 Model 等按一定的目錄結構組織成的完成某些功能的可以重用的集合。這是 UCM 所引入的概念， Component 與 UCM Project 相關聯，不可拆分，便於重用。。有人比喻成複寫紙。非常貼切。其他project想引用馬上可以複製進去。

既然一個comonent是一組檔案，那麼它可以把一個普通的vob庫構成component，也可以把一個VOB庫的某個資料夾看做component，但是必須是vob庫的一級目錄

update：2010-07-22：摘自CCRC7.0IDE外掛中文幫助文件
UCM 使用者依靠專案經理來建立專案、將專案的共享資源（檔案和目錄）組織到元件中，然後指定用來指導團隊修改和整合元件的基線、活動和流。

UCM 元件是團隊將之作為一個整體進行開發、整合和釋出的共享資源集合（例如類庫或使用者介面模組）。 UCM 專案包含一個或（通常）多個元件，這些元件經常為其他專案所共享。通常元件作為 VOB 中的頂級目錄建立。VOB 可以包含一個或多個元件，但是一個元件不能包含其他元件。

注： 您不能使用 ClearCase Remote Client 來建立、修改或檢視現有元件。要處理元件，您必須使用僅在本機 Rational ClearCase 客戶端上可用的工具。有關元件的更多資訊，請參閱 ClearCase 文件。

基線 (Baseline)（新增） ： 在UCM 模型中，當一個 ClearCase 物件典型地代表一個或多個元件地穩定地源配置時，專案經理就生成基線。基線標識了一個元件或多個元件中所 有元素 (Element) 的某一個版本和這些元素的活動。簡單的說，基線就是元件的一個版本。你可以從基線生成開發流或者為一個已有的開發流基線更新 (Rebase)，一個基線是一個構件在一個特定時刻的一個快照。

baseline = code + documents

baseline1  + changesets = baseline2
基線有雙重的身份，大家可以在下圖我畫的簡略圖中發現一條基線 從compoent的角度看它是屬於某個comopent的基線，如果從流的角度看，基線是在某個流中產生的基線，我們有一點要記住，基線的產生是通過流建立的，但是我們從隸屬的角度上看他是屬於某個component的基線。

Deliver （新增） ： UCM的概念，是一個從開發流向 UCM Project 整合流或其他開發流提交工作的一個動作。

Rebase （新增） ： UCM模式的一個操作，讓當前 Stream 的 View 的內容與 Integration Stream 推薦基線同步。並且只工作在基線（非活動）的粒度上。

Snapshot view ： Snapshot View 是對 VOB 的一個靜態檢視，將相關的 VOB 的選定的版本下載到本地儲存，需要經常進行 Update View 操作以保證與關聯的 stream 同步。

Dynamic View ： Dynamic View 是對 VOB 的一個動態檢視， VOB 的變化會及時反應到 Dynamic View 上，每個 Dynamic View 都關聯到一個 Stream 上，在 Dynamic View 上會有一些 View 的私有檔案，這些 View 私有檔案不會被同一個 Stream 上的其他 View 所見到。

UCM概念和BASE的對應，看完基本上知道什麼回事了。

update：2010-07-08：上圖中說的神似的幾對概念，從實現的功能角度確實差不多。不過具體的實現機制等還是有很多不同。

這個在後面的文章中有討論

 其他一些比較

圖

update 2010-07-07，來源 地址 ，作者：grantlee

一、基線不是基於元件的，而是基於流的；基線和流的關係猶如工件和檔案的關係，因為：
1、工件是檔案的一個版本，一般用file.no形式描述。
2、工件是活動產生的結果，工件是不可編輯的（因為編輯也是活動，又產生新的工件，原有的工件沒有變化）。
所以：
1、基線是流的一個版本，預設用stream＋date的形式來描述。
2、基線是一組工件的集合，工件覆蓋了流中所有的檔案。

上面是不是還是有些糊塗？因為沒有討論元件、流、檔案三者之間的關係。
1、元件是一組檔案（目錄）的集合；
2、流是元件的一個工作分支；
3、流中包含了元件中的所有檔案；

是不是還沒有說清楚？越來越糊塗了？^_^
將元件想象成一張紙，目錄樹和檔名就可以寫在上面了，這個就是元件和檔案（目錄）的關係；
將這張紙影印一下，所有的目錄和檔案也有了，影印出來的流了；
反過來說原來的也是一張紙了，那麼也是流了？
不錯，原來的那張紙也是流，是主流（Main），一般都不用的。最後歸結：元件原來是一沓影印出來的紙，只是每張紙上都可以再手工修改，最奇妙的是手工修改過的還可以影印到其他指定的紙上！哈哈，原來是複寫紙。

update 2010-07-15 來源 地址 ，作者：lin85210

vob就是倉庫，component是工具箱（還有其他類別的工具箱），element就是鉗子，扳子，斧頭等等，我們就是工人。

update：2010-07-22：摘自CCRC7.0IDE外掛中文幫助文件

無論您使用的是 UCM 還是基本 ClearCase，都存在這些分支、版本和標籤；在 UCM 中，您不必直接對它們進行處理。

update 2010-08-03 UCM中同時使用Baseline和label

UCM更有彈性的應用方式

為了配合客戶所提出的需求，依據MR狀態來建立不同的Build，同步到對應的測試環境，原先的UCM建立baseline模式已不敷使用！
引入base clearcase apply label的觀念，再加上make baseline by import label，就可以達到依據不同的label建立不同的baseline，而不會侷限在有變更才可以建立baseline！這樣的方式相對彈性許多！

 實際會用到的指令如下，之後可以用程式的方式作到自動化：

cleartool lsbl -short -comp [email protected]/twm_vob
列出某個component中，所有的baseline

cleartool lsbl -short -comp [email protected]/twm_vob -stream [email protected]/twm_vob
列出某個component中，位於某個stream中所有的baseline

cleartool rmbl [email protected]/twm_vob
移除某一條baseline(這個動作會將對應的label type也一併移除)

cleartool mkbl -nc -import -comp [email protected]/twm_vob,[email protected]/twm_vob[email protected]/twm_vob
以import label的方式建立baseline，這邊要特別注意，最小的單位是component，也就是說label要貼到某個component中所有的檔案，否則無法建立
baseline baseline的naming rule是 __IMPORT，還沒找到可以在哪邊修改naming rule

cleartool rename lbtype:[email protected]/twm_vob lbtype:[email protected]/twm_vob
將label type改名，對應所有的instance(label)會自動更新

cleartool rename baseline:[email protected]/twm_vob baseline:[email protected]/twm_vob
將baseline改名

cleartool rebase
label與baseline都改名後，再進行rebase，若是先rebase再改label type的話，檔案會看不見，要重新rebase一次才可以(先rebase到別條，再rebase回來)