我的理解原文：
如果要針對
deliver_start
這個建立
trigger
，則要了解
deliver
這個clearcase
操作具體步驟，以下是我對
deliver
這個clearcase
操作的理解： 1.
檢查當前流上是否有乙個
deliver
或rebase
正在進行中，如果有，則提示當前正有乙個
deliver
或rebase
過程在執行中。 2.
檢查目標流的
deliver policy
，如果不符合
stream policy
，則拒絕執行
deliver
並給出提示。 3.
檢查源流的
deliver policy
，如果不符合
stream policy
，則拒絕執行
deliver
並給出提示。 4.
選擇要提交的活動，檢查活動的依賴關係。 5.
確定將要進行操作的目標流的檢視。 6.
檢查確定的目標流操作檢視上目前是否有
check out
的配置項，如果有提示，在要提交的目標流的操作檢視有
check out
操作，退出。 7.
開始執行
deliver
操作，這裡是
deliver_start
的開始；建立
deliver
活動，將要操作的目標流檢視的當前活動設定為該
deliver
活動，一般情況下，在
deliver
沒有完成前在圖形介面下與命令列中不能修改該檢視的當前活動，但是可以通過一些特殊方法進行修改。在這一步開始後，如果以後的任務失敗，則要執行
deliver –cancel
才能刪除
deliver
活動，並對
check out
的配置項進行
undo check out
操作。
8.獲取每個要提交的
activity
的變更集。 9.
對所有需要在目標流上進行操作的配置項執行
check out
操作，如果發現當前有配置項已經被
check out
，記錄錯誤並繼續執行，在所有的
check out
操作執行完畢後，給出在
deliver
目標流操作檢視上無法執行
check out
的配置項列表並中止
deliver
活動。注：在第
6步檢查的只是目標檢視上是否有
check out
，可能在其他檢視上有
check out
操作，執行
deliver
時，要求配置項的
check out
型別為reserved
型別，如果配置項已經在其他檢視上進行了
check out
操作，則不能進行
reserved
型別check out
操作，無法保證在
deliver
結束可以執行
check in
操作，所以不能繼續進行
deliver
的歸併。
10.
將要提交的配置項與目標流上已經
check out
的配置項進行歸併，根據設定進行自動歸併或人工歸併，如果自動歸併失敗，進行人工歸併，如果某一配置項歸併沒
有完成，記錄錯誤並繼續執行，在所有的歸併執行完畢後，給出歸併失敗的列表並中止
deliver
活動。
11.如果沒有設定
-force
或是在圖形介面下，歸併完成後，提示使用者
deliver
操作歸併完成。在此步還可以對
deliver
操作進行回滾，到達第
12步後，則不能進行回滾操作。
12.
在本步執行之前都可以執行
deliver_cancel
操作；本步活動是
deliver_complete
的開始；對所有
deliver
操作的check out
的配置項進行
check in
，在提交的源流打上乙個隱藏的
delivered label
，同時結束對目標流操作檢視當前活動的鎖定，
deliver
操作至此全部結束。
以上步驟是我對
deliver
操作的理解，不是
rational clearcase
給出的指南，由於沒有足夠資訊，所以可能和實際情況有一定偏差。從以上步驟可以看到，在前
6步進行過檢查的，不必設定
deliver_start
的preop
型別的trigger
進行重複檢查。
在clearcase 7.0文件中的官方解釋如下（簡單的翻譯，不保證完全無誤，另需要注意的是這份文件針對的clearcase 7.0，並不一定對clearcase 6.0相容）：
啟動deliver操作後，將要deliver的流的狀態將會被置為deliver-in-progress，注意不是目標流。
檢查所有提交的活動之前的依賴關係
檢查所有的目錄配置項，如果發現提交流與目標流有不同，則在目標流上checkout並進行merge，如果由於目標流上已經對目標項進行了reserved check out ，merge失敗，則提交停止；這時所有已經歸併成功的目錄配置項在目標流上儲存merge結果。
對所有需要歸併的配置項進行checkout，如果不能進行reserved型別的check out，跳過該配置項，繼續嘗試對其他需要歸併的配置進行check out
如果不能將所有的配置項checkout，則以下步驟不會進行，有兩種選擇
回退你的deliver
解決不能checkout的問題，例如由於其他人正在進行deliver操作，所以不能checkout，則等其他人deliver完成或回退後再執行deliver
所有需要提交的配置項都要checkout成功後，開始merge，如果自動merge不成功，則需要手工merge
所有merge成功後，建議在目標流是進行build並測試
build沒有問題，complete提交流，將提交流的狀態deliver-in-progress取消
從新的clearcase文件來看，我的描述基本正確，但是有些深層的，如提交流的狀態我沒有注意，還有許多需要學習
Makefile執行過程例解
1.一次讀取變數 makefiles 定義的makefile檔案列表 2.讀取工作目錄下的makefile檔案 根據命令的查詢順序 gnumakefile makefile makefile 首先找到哪個就讀取哪個 3.一次讀取工作目錄makefile檔案中使用指示符 include 包含的檔案 4...
Springboot整合junit過程解析
對m en專案的pom.xml進行配置 org.springframework.boot spring boot starter test程式設計客棧 www.cppcns.com art程式設計客棧ifactid test tmudjxddqdons org.junit.vintage junit...
springboot vue開發過程出錯解決思路
本文旨在記錄專案跑起來之後開發過程中遇到的問題的解決思路。前端推薦使用webstorm,後端推薦使用idea 當問題出現後，首先分別要看的就是這三個控制台，webstorm 頁面 f12 和idea。一般情況下頁面控制台給的資訊最多，它有url 狀態碼和message等資訊，通過狀態碼可以知道後端的...