終於搞定了一個UCM實例的配置
中途有個插曲，我操作過程中涉及到了兩臺服務器，然後我分別用系統本身的管理員賬戶administrator進行操作，
最後兩邊創建的東西不能夠互通。最後才知道CC這玩意，對賬戶權限要求有點變態。最好使用域賬戶。
先不在權限上面花過多時間。只要知道，以後用域賬戶就行了。
其實剛纔的例子中一共有幾個問題：
1：CCCQ集成的策略 ，選項蠻多的，沒有明白
2：UCM的stream 裏面的stream，child stream什麼的，流嵌套流，平行級別流。沒太明白
update：2010-07-08：
一個流是一個長期存在的Rational ClearCase對象。
一個用戶確定哪些元素版本將出現在視圖中的UCM對象（類似Base裏面的config spec），以提供你去查看修改或者構建。
維護一組基線和活動的列表。
UCM中使用基線和活動來描述一個 流的構造。（可不可以簡單理解爲流就是基線和活動打包而成的東西？）
當您創建一個流，初始化的構造和基線相同（也就是說，一個組件包含了每個元素的單個版本）。
當您修改流的構造，您分配的修改一個或多個活動。因此，一個流的構造是一個給定的基線及一個或多個活動 。
所以rebase，deliver 其實就是雙方基線的交互，（默認是父子之間，不過平行流也可以的）
rebase的時候，A-B，A從B得到一個推薦基線，獲取B的最新內容
deliver的時候，A-B，A把自己的基線給B，把A的最新內容給B
一個項目包括兩種流：集成流，開發流
平行流有公共的上級流，管理上可以當分支來看，平行開發和管理代碼，父子流，一般是把項目的穩定的版本放到父流上。如果做deliver默認是從子流到父流，rebase是相反的。平行流之間也可以進行代碼溝通，相互之間也能deliver和rebase.父子的在管理上分得更清晰一些,不過父子有一個隱含基線的限制，造成不好用。所以兩者互相有好壞。當然每個公司的開發流程不一樣，這個還是要具體情況具體分析。
3：基線的種類和級別 ，沒太明白
4：component和VOB關係 ，沒太明白，
update：2010-07-08：component是邏輯的，VOB是物理的 。vob真實的存在，但是component是把vob劃分成一個集合，或者多個集合。。。component是個物理資源的再整合，只能映射VOB本身或者VOB的第一級目錄。
5：CC中的權限 ，沒太明白
其他一些收集到的文章，文章1 ，