上篇文章中的鏈接搞錯，
clearcase的實施方案 ，Base的。其實就是較多的使用分支和標籤兩種策略
用來初步明白Base項目差不多。深入的還需要看更多的資料
先講下UCM的發展歷史，1999就提出了，然後到現在已經10多年了。所以算是相當成熟了，IBM官方出了一些文章講述UCM，介紹的非常好。 好文章1 ， 好文章 2， 網友的一個文章 ，
看下概念：（黑色下劃線粗體是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的概念，可以理解爲項目的主幹，每個開發流都是集成流的一個分支，在開發流上完成工作後，再提交到主幹，項目的 Build 環境建議採用集成流。
在一個項目的幹流上（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 文檔。
Change Set（新增） ： Change Set 記錄了 Activity 所關聯的所有的配置項的版本變更，每個 Activity 都有一個 Change Set 。
基線 (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 doc@/twm_vob
列出某個component中，所有的baseline
cleartool lsbl -short -comp doc@/twm_vob -stream twm_eva_developer@/twm_vob
列出某個component中，位於某個stream中所有的baseline
cleartool rmbl UT_Test_Passed_doc_IMPORT@/twm_vob
移除某一條baseline(這個動作會將對應的label type也一併移除)
cleartool mkbl -nc -import -comp doc@/twm_vob,src@/twm_vob UT_Test_Passed@/twm_vob
以import label的方式建立baseline，這邊要特別注意，最小的單位是component，也就是說label要貼到某個component中所有的檔案，否則無法建立
baseline baseline的naming rule是 __IMPORT，還沒找到可以在哪邊修改naming rule
cleartool rename lbtype:UT_Test_Passed_doc_IMPORT@/twm_vob lbtype:UT_Test_Passed_20070816@/twm_vob
將label type改名，對應所有的instance(label)會自動更新
cleartool rename baseline:UT_Test_Passed_doc_IMPORT.8278@/twm_vob baseline:UT_Test_Passed_doc_20070816@/twm_vob
將baseline改名
cleartool rebase
label與baseline都改名後，再進行rebase，若是先rebase再改label type的話，檔案會看不見，要重新rebase一次纔可以(先rebase到別條，再rebase回來)
