1 簡介

1.1 目的
本文的目的是介紹某公司在將軟件資產從javascript:;" onClick="javascript:tagshow(event, '%C6%E4%CB%FB');" target="_self">其他配置管理工具遷移到IBM Rational公司的ClearCase UCM配置管理解決方案的一些經驗。

1.2 概念
在使用ClearCase之前，必需理解某些概念：

• Element 納入配置管理的包括版本信息的配置項，包括文件與目錄。
• VOB Version Object Base，存放配置項的庫。
• UCM Unified Changed Management的縮寫，統一變更管理模式
• Activity Activity是ClearCase UCM模式中的一個概念，通過變更集(Change Set)跟蹤完成一項開發任務所引起的所有配置項的變更。在UCM模式下所有的Check Out、Check In、Add to Source Control等引起配置項發生變化的操作必須關聯到一個Activity。
• Change Set Change Set記錄了Activity所關聯的所有的配置項的版本變更，每個Activity都有一個Change Set。
• Component 可以理解為一些代碼、文檔、Model等按一定的目錄結構組織成的完成某些功能的可以重用的集合。這是UCM所引入的概念，Component與UCM Project相關聯，UCM Project所管理的所有的Element必定從屬于一個Component，每個UCM Project至少有一個Component。
• Deliver UCM的概念，是一個從開發流向UCM Project集成流或其他開發流提交工作的一個動作。
• Development Stream UCM的概念，可以理解為一個獨立的開發環境，包含了在這個開發流上的Activity與修改的配置項的版本，UCM通過開發流簡化了并行開發的配置管理工作。
• Dynamic View Dynamic View是對VOB的一個動態視圖，VOB的變化會及時反應到Dynamic View上，每個Dynamic View都關聯到一個Stream上，在Dynamic View上會有一些View的私有文件，這些View私有文件不會被同一個Stream上的其他View所見到。
• Integration Stream UCM的概念，可以理解為項目的主干，每個開發流都是集成流的一個分支，在開發流上完成工作后，再提交到主干，項目的Build環境建議采用集成流
• Project 是ClearCase UCM的一個概念，包含了配置管理所需要的一些配置信息，如果Component、Baseline，Stream等，每個Project都有一個Integration Stream。
• Project VOB(PVOB) 是存儲UCM所需要的一些特殊的信息，如Proejcts，Stream，Activity及Change Sets等，一個PVOB可以包含多個Project的信息， Project的信息必須保存在PVOB中。
• Rebase UCM模式的一個操作，讓當前Stream的View的內容與Integration Stream推薦基線同步。
• Snapshot view Snapshot View是對VOB的一個靜態視圖，將相關的VOB的選定的版本下載到本地保存，需要經常進行Update View操作以保證與關聯的stream同步。
• Add to Source Control 執行將選定的文件或目錄納入ClearCase管理的動作，需要注意的是，如果要在某一目錄下添加文件或目錄，必須先將它所在的目錄先Check out，再在該目錄下執行Add to Source Control動作，而后再對當前目錄執行Check in；如果正確執行完成后，該文件與目錄后的類型會變為File element Version或Directory Version，如果沒有將當前目錄Checkout就執行Add to Source Control，則在執行完成后文件的類型還是View-private File或View-private Directory，在這種情況下，該文件或目錄實際上沒有納入配置管理。

2 計劃與準備

2.1 計劃
配置管理切換大至可以劃分為以下幾個階段：計劃，準備，配置庫的遷移，正式使用。

配置管理切換計劃的主要內容包括進度、資源等。

項目的規模與所處的階段不同，則配置管理切換所需要的時間也不同。一個20人左右，開發進度約達到計劃的一半，代碼量達到50K左右的項目，從開始計劃到配置管理完全切換到ClearCase，最少需要3-4周時間。如果盲目的追求進度，想在1-2周內切換完成，則可能在切換后產生一系列后遺癥，如版本丟失、版本錯誤甚至可能會有部分項目組成員抵制，從而使項目開發進程中部分工作不能納入配置管理之下。

進度安排建議：根據項目的情況用5-15個工作日進行準備，配置庫的遷移需要5個工作日左右的時間，配置管理工程師要用5-10個工作日的跟進以使項目組成員熟悉并不再需要幫助。

任何計劃都有一個前提：資源，不同的資源會導致不同的進度與成本。在配置管理切換中三類資源非常重要：經過培訓并且有ClearCase經驗的配置管理工程師；經過培訓并了解ClearCase UCM概念的項目經理與架構師；Rational工程師的及時支持。

配置管理工程師在這3-4周時間內要沒有其他的任務的打擾，全部的時間應用于該項目的配置切換；每個項目在配置切換的準備階段如果有Rational工程師的現場支持會少走許多彎路。

為了更好的完成工作，配置管理工程師必須經過系統的ClearCase的培訓，同時為了提高配置管理工程師的能力，建議在內部建立一個獨立的試驗環境，可以讓配置管理工程師從安裝配置Server開始，進行ClearCase的各種功能的操作試驗，以獲得經驗。

2.2 準備
如果決定應用ClearCase，好的計劃與充分的準備會起到事半功倍的效果。一個項目從啟動就應用ClearCase則相對于從其他配置管理解決方案遷移到ClearCase在準備上要容易的多，包括多個版本分支的產品的配置遷移則更加困難，如果準備不充分，可能會造成多次反復、嚴重降低工作效率，甚至可能會造成版本錯誤等嚴重后果。

首先，要決定是應用ClearCase UCM還是Base ClearCase，UCM模式是基于Base ClearCase應用Activity管理變更的一種模式。如果項目組全部在UNIX上進行開發，比較熟悉CVS，對命令行及Shell很熟悉，項目團隊配合時間較長，有專職配置管理工程師，建議應用Base ClearCase，但是需要自行開發腳本，以利于項目組成員的使用；跨平臺項目、配置管理工程師是與其他項目共用的、需要對項目的進度與活動有較高的透明度等建議應用UCM模式。本文主要探討UCM模式。

在準備的時候要確定當前項目與其他的項目的關系，以確定PVOB的建立，如果項目和其他項目的關系不是很緊密，建議創建一個獨立的PVOB。因為一般PVOB不占用過多的資源。

2.2.1 配置模式

PVOB建立完成后，要根據項目的實際情況確定項目的開發模式，這里給出一些建議。

2.2.1.1 共享流模式

項目只有一個單獨的集成流，沒有開發流。適用于調研項目或規模較小，且目標單一，不會同時有多個變更存在的項目。比較大的項目也可以在實際項目的初始階段建立一個UCM Project，采用共享流模式，在需求完成后，在這個Project的Component上建立Final基線，在這個基線上建立一個新的多開發流模式的UCM Project進行設計與編碼。

優點：控制簡單，如果設置的是Dynamic View，每個人的修改，其他人可以立即看到，不需要deliver，對有大量文檔的項目較適合；不需要針對Deliver及Rebase設置大量的基線，配置管理人員的工作相對較少；同時項目配置管理的Policy也比較簡單，不需要考慮太多。

缺點：如果同時支持多個不同的客戶或同時有多個變更，這些變更之間互相影響，則會產生開發的混亂。

在Clearcase中共享流模式也支持同時多個用戶對同一文件進行Check out操作，并在Check in時進行歸并。但是如果多人對一個Element進行Check out操作時，只有一個人可以應用Reserved checkout，其他的項目組成員只能進行Unreserved Checkout。Reserved Checkout保證了開發人員是在最新的一個版本上進行Checkout，只有在Reserved Checkout的人Check in之后才可以Check in并進行歸并。Reserved與Unreserved的區別可見圖一。

2.2.1.2 多開發流模式

項目中有多個不同的開發流，每個開發流都是一個獨立的分支，如果項目需要還可以建立多層次的分支，支持并行開發，適于超過10人，較復雜的項目。如果項目極復雜，可以分為多層開發流與集成流，如圖二。優點：可以并行開發，每個Stream都相當于一個獨立的開發環境，每個人之間的工作不會互相產生干擾；可以通過Policy的設置更好的進行配置管理。

缺點：不同的Stream之間的Deliver與Rebase會產生問題；在merge時也有可能會產生問題，而且對Word等二進制文件的merge支持不好；在修改完成之后，每個Stream上的修改只有deliver與Rebase才能被其他的stream應用，不能及時反映變化；Policy的設置較復雜。

在多開發流模式下可以根據需要將某個stream設置為只讀模式。

建議：可以根據需要建立一個多開發流模式的Project，但是在初期階段不設立開發流，在進行詳細設計階段后再建立相應的開發流。

2.2.1.3 Project組模式

Project組模式是以上兩種模式的組合，適用于產品類項目，在這種類型中，設立一個主干Project，針對不同的客戶或不同的變更，在相應的baseline上建立新的共享流Project去處理，而不是在多開發流中的Project新建一個開發流。如果其中某個客戶的要求或變更比較復雜，也可以建一個多開發流的Project進行處理。

優點：可以根據任務的實際情況靈活處理變更等，而且如果發現對所有用戶都需要的變更可以在主干上修改并發布到各個子Project上，也可以在一個子Proejct上修改，經驗證后再發布到其他子Project，對于有長遠規劃的產品非常適合。

缺點：如果在最初架構師考慮不周，Component劃分不合理在后期會比較困難；不同Project之間的Deliver需要更復雜的Policy，需要配置管理工程師極有經驗。

2.2.2 Activity的命名準則

建議對不同類型的工作可以通過Activity的命名直接區分，建議如下：

新加功能為：Feature_功能名

變更的執行：CR_變更號
注：如果變更中涉及到文檔的修改，則文檔修改也應用此Activity

修改Bug：Bugfix_BUG號
注：BUG號來自ClearQuest

文檔：Doc_文檔名
注：在變更及Bugfix中文檔的修改activity應用變更的activity

計劃的更新：Plan_Tracking_時間
另一建議為選用ClearQuest為缺陷管理工具，并將ClearCase與ClearQuest集成，這樣所有的Activity可以通過ClearQuest獲得。

2.2.3 Deliver與Rebase的準則

項目中需要明確Deliver與準則，包括什么情況下可以Deliver，Deliver前是否全部文件都Check in，是否可以向非本項目的Stream進行Deliver等，這些需要根據實際情況確定，但是為了盡量避免沖突，建議在Deliver前要求進行Rebase。

項目經理、架構師與配置管理工程師要一起確定項目配置的邏輯視圖，配置管理工程師要根據情況確定配置的物理視圖。ClearCase的UCM模式中的Component可以理解為配置的邏輯視圖，而VOB的設置可以理解為配置的物理視圖。

2.2.4.1 配置存儲的邏輯視圖：Component

Component可以從系統的架構導出，如果應用RUP或項目有Deploy View或Implementation View則可以從中導出Component。

大多數從其他配置管理工具切換到ClearCase的項目將所有的代碼作為一個Component，這樣雖然簡單，但是就失去了使用ClearCase的意義，可以按模塊或3-Tier架構來分解代碼，這樣也利于項目組成員理解項目。Component的主要作用就是用于重用；設置Component的另一個目的是代碼的權限控制，如果有外包或實習生一同工作，可以將核心代碼設置為一批Component，將可以由外包或實習生接觸的代碼設置為一批Component，通過對Component的權限進行設置，可以防止惡意獲取或修改代碼的可能性。

文檔可以按以下兩種方式進行管理：

• 單獨設置一個文檔VOB，所有的文檔都放在一起，優點是權限控制簡單，可以將文檔提供給其他人員而不用擔心代碼的泄漏，缺點是代碼與文檔分離，工作中可能會出現兩者不一致的問題。
• 根據架構，同一模塊或Tier的代碼與相應和文檔一個Component中，優點是可以保證文檔與代碼的一致性，但是這時要保證代碼與文檔的安全性要繁瑣一些。

Rational公司給出了Component及目錄的設置，可以參考。

2.2.4.2 配置的物理視圖

Component只是ClearCase UCM模式的邏輯視圖，而實際的存儲與控制是由VOB實現的，通過對VOB的訪問控制實現對Component的控制。從安全與實用的角度出發，建議每個項目的VOB獨立，不要幾個項目共用一個VOB。如果一個項目非常重要，對代碼等軟件資產的管理要求嚴格，建議將文檔、核心代碼、非核心代碼分別設置為三個VOB，這樣可能對Server的硬件資源較高，但是安全上帶來的好處足以彌補硬件上額外的開支。Component可以是VOB或VOB的一個子目錄，需要注意的是VOB只有第一級子目錄才可以設置為Component。

在不同的PVOB中可以Import同一個VOB或其子目錄作為Component，但是這時一定要注意，并規劃好各分支的關系。

2.2.5 配置庫安全設置

配置模式、項目配置的邏輯視圖與物理視圖確定之后，配置管理工程師要和項目經理一起確定配置庫及配置項的安全設置。ClearCase的安全設置和Winodws、Unix系統相關，在本文只介紹Windows下的設置。

ClearCase中Windows域中有一個特殊用戶clearcase_albd，Clearcase系統要求對所有的VOB與View共享目錄，該用戶均有完全控制權限，所以該用戶的安全非常重要；而且由于在每個客戶端中設置了Atria Location Broker服務，該服務是以域用戶clearcase_albd啟動，所以如果修改clearcase_albd用戶的密碼，需要變更每個客戶端的密碼（見圖）。建議該用戶密碼至少12位，要為無意義的字符串，要包含數字、大小寫字母與特殊字符。

ClearCase的安全設置有三個部分：

• 配置庫存儲目錄的安全設置
• 配置庫的安全設置
• 配置項的安全設置

以上的所有安全設置都是基于windows域的安全組，項目經理要根據項目的人員分布與代碼保密的原則確定人員的分組，明確不同組的人員的代碼權限，配置管理工程師負責與域管理員聯系建立用戶與組。

從工作的方便性與軟件資產的保護原則出發，建議每個項目設置一個quality組，項目經理、配置管理工程師與質量經理是該組的成員。

在ClearCase的VOB服務器上需要建立一個共享目錄用于存放用戶共同訪問的VOB的物理實體。

該共享目錄的權限設置為所有的開發人員都有讀寫權限。為了保證VOB實體的安全性，在該共享目錄之下要設立另一個目錄用于直接存放VOB的物理實體，對所有的開發人員是讀寫權限，對配置管理工程師、clearcase_albd需要設置為完全控制權限，該部分設置一般不需要進行，在create VOB及應用命令cleartool protectvob時，ClearCase會自動設置。

VOB實體的屬性中包括owner，group與additional group，owner表示誰擁有該VOB，group表明該owner是哪個組的，additional group描述了還有哪些組對該VOB具有操作的權限。如果在配置項中設置了其他組可讀，但是如果用戶的組沒有在group或additional group中則用戶無法獲得配置項，這樣可以保護一些核心代碼等，所以建議核心代碼單獨設置為一個VOB。VOB的權限設置可以通過命令行來進行設置：

cleartool protectvob

具體的使用方法可以用cleartool man protectvob獲取幫助。

配置項的安全設置類同UNIX。需要注意的是在ClearCase中目錄也是作為配置項進行管理的。在使用中要注意的是ClearCase的GUI界面不支持遞歸，所以如果想修改某一目錄及之下所有子目錄的權限設置，請應用命令行進行。

2.2.6 環境的準備

圖五：配置系統架構圖

上圖是Rational建議的服務器的配置的邏輯視圖。以下是一些要求：

• 網絡要求
  ClearCase支持客戶/服務器（C/S）以及瀏覽器/服務器（B/S）兩種使用方式，要求客戶機和服務器通所在的網絡環境支持TCP/IP，局域網均能滿足要求，建議100兆以太網。
• 操作系統要求
  如果在Windows環境下部署ClearCase，首先應滿足ClearCase要求的平臺條件（如Windows2000需SP2以上等），其次需要所有開發機器均在要加入Windows域以進行統一的用戶校驗和安全性管理。如果在Unix環境下部署ClearCase，同樣需滿足ClearCase要求的Unix條件（如打上ClearCase需要的操作系統補丁等）。
• 硬件要求
  Windows環境下，VOB Server建議CPU P3-1GHz以上，內存512MB以上，硬盤空間80GB以上，如果有可能，最好采用服務器。

如果單純從性能考慮，VOB Server最好采用UNIX系統，但是在實際情況中要考慮到易用性等，如果項目組成員大多數采用Windows平臺進行開發，建議還是使用Windows系統做為VOB Server，因為如果采用UNIX VOB Server，如果想在Windows平臺上使用Dynamic View會有一定的困難。

在實際中可以將VOB Server與License Server及Registry Server配置在一臺機器上。這些Server中只有VOB Server與View Server的對配置的要求比較高，而且一個Registry Server上只能啟動一個Windows Region與UNIX Region，所以建議每個項目配置一個Registry Server，配置項目自己的Region。

在實際使用過程中，最初所有的View均保存在項目組成員的機器上，但是在使用中出現一系列問題，如果項目足夠的資源，建議配置一個獨立的View Server，項目組成員的所有Dynamic View要求必須建立在View Server上。

在環境的準備過程中，要考慮到開發人員的開發習慣與測試環境等問題，決定VOB Sever是安裝在Windows平臺還是安裝在Windows平臺。在決定安裝平臺后，要根據開發模式確定是否安裝Web Server，如果項目會有大量的在外支持的工作，并要求在客戶現場修改代碼，建議安裝在辦公網段，這樣可以通過外網進行訪問；如果是產品項目在公司內部研發，沒有遠程修改的需求，建議安裝在實驗網段。

在Server安裝完成后，要根據代碼保密與配置管理等原則等將所有的用戶與用戶組在域中建立，并將網絡安裝包共享給用戶使用，要注意有是在某個域上安裝了ClearCase客戶端后，并不能直接在另一個域上使用，需要修改Atria Location Broker這個服務中啟動用戶與密碼，所以在安裝完成后，不能對clearcase_albd的密碼進行改動，所以clearcase_albd這個用戶設置中一定要注意設置密碼永不過期。如果一個項目組成員想在不同的域并且這些域之間沒有信任的情況下都使用ClearCase，只能安裝兩套操作系統，在每個系統上都安裝ClearCase客戶端。

2.2.7 舊版本的整理與版本的遷移

在服務器安裝完成后，要考慮舊版本的整理，如果只是簡單的將VSS與CVS的全部配置項移到ClearCase中去，就只是將ClearCase當做VSS與CVS使用，使用ClearCase也沒有什么意義，所以要將舊有的配置項進行整理。這項工作應在配置庫的邏輯視圖與物理視圖確定之后就開始，一直持續到版本的遷移。

在整理舊有的配置項時要先將原有的VSS或CVS配置庫進行備份，而后在備份的配置庫進行整理，以防止對工作中的配置庫造成損壞。版本整理的時候可以將文檔與代碼重新按照Component結構設置。

在VSS中為了工作方便，常常將工作庫，受控庫與基線庫分離，而且VSS的分支功能并不是很好，針對不同的客戶修正一般都會新建一個目錄來進行修改，同一個配置項在配置庫中存在多個副本，為配置管理帶來許多人為的不可控因素。

在整理VSS配置庫時，一般情況下文檔部分可以只采用Get last version的方法，取出最新版本，按規定放入Component即可；代碼的處理有所不同，如果所有的代碼在VSS配置庫中只存放在一處，之后在此基礎上設置label，則可以應用命令clearexport_ssafe與clearimport將其導入，在導入結束后將所有的label導入到相應的Component上即可；如果有多處副本只能將每處副本的相應基線應用get last version命令取出，而后將用clearfsimport導入Clearcase，之后在相同目錄下重復以上動作，要注意的是每次clearfsimport后要建立一個基線。

針對一些有長年積累，在VSS上有多個目錄存放不同的版本的項目，不要有必其功于一役的不切實想法，應先整理以前的版本，找出幾個主要版本樹，將各個版本之間的關系理清楚，之后將幾個版本樹按以上的方法導入。

如果源代碼在原項目中是應用CVS進行配置管理，一般情況下，在CVS中沒有副本存在，可以應用clearexport_cvs命令與clearimport命令導入好可。

在應用clearimport時要注意，如java中文件名是區分大小寫的要應用clearimport -p，具體方法可以應用cleartool man clearimport來查看幫助。

2.2.8 客戶端的安裝與培訓

每個項目在安裝時要根據安裝手冊制定本項目自己的安裝手冊，根據項目實際情況修改后發布給項目使用。在所有的客戶端安裝后，項目配置管理工程師要準備培訓材料對項目組成員進行培訓，培訓中要講清楚項目的PVOB、開發模式、Component的設置、分組與權限的設置、Stream的設置、項目配置的Policy、Activity的命名準則、Deliver與Rebase的要求等實際情況，而不是只講共性的一些東西。

2.2.9 試用

如果大部分項目組成員以前沒有過ClearCase的使用經驗且進度允許，則在客戶端安裝及培訓完成后，要在項目組內部進行試用，以讓項目組成員熟悉；最好是ClearCase與VSS或CVS并行使用一周左右時間，然后再將配置管理完成切換到ClearCase。

3 VSS遷移的步驟

3.1 一些前提條件
3.1.1 軟件安裝

必須在ClearCase的VOB端安裝VSS服務器程序。

3.1.2 用戶權限

對于Visual Source Safe，要以對Visual Source Safe系統中所有工程/文件均具有完全權限的身份操作；

對于ClearCase一側，要ClearCase管理員的身份操作；

因此在遷移時，最好選用同一個帳號(口令亦相同)，同時具有以上兩個權限。

如果你的ClearCase帳號不具有以上權限，請與你的系統管理員聯系。

3.1.3 日期/時間格式

在遷移過程中，ClearCase對時間要求比較嚴格，且用到的是短時間格式，具體設置如下：

1、 打開控制面板的區域設置屬性；

2、 在時間欄中，將時間樣式設為"h:mm:ss tt"；
將時間分隔符設為":"；
將上午符號設為"AM" ；
將下午符號設為"PM" ；
注意以上設置值的大小寫！

3、 在日期欄中，將短日期樣式設為"M/d/yy"；
將日期分隔符設為"/" ；
設置完后可查看資源管理器中文件的時間屬性以檢查上述設置的正確性。正確的修改應為：5/21/01 11:00 AM

3.1.3.1 環境變量

為方便操作，可添加以下系統環境變量：

變量名PATH    
變量名 ？？\Microsoft Visual Studio\vss\win32； //VSS中ss.exe路徑？？\rational\clearcase\bin；
             ？？\rational\clearcase\etc； //ClearCase中clearexport_ssafe.exe路徑
以上？？用戶實際應用程序路徑。
設置ssdir環境變量為vss數據庫文件的路徑;
設置ssuser環境變量為vss登錄用戶名(為方便使用,可將該用戶的密碼設為空).

ss dir: 顯示當前的Project;
ss cd $/SW:設置當前的Project為SW;
ss whoami:顯示當前的登錄用戶;

設置完畢后，可在命令行界面下運行path查看以上設置是否生效。

3.2 建立VOB
建立VOB需要注意的是當前的用戶與主組，建立用戶時的用戶與主組就是VOB的Owner與Group，但是有時會出現用戶的主組并不是所期望的Group，這時可以應用命令修改vob的owner與group。

cleartool protectvob -chown user -chgrp group -r VOBPNAME

3.3 建立General View
在建立VOB可以建立general view，以后所有的遷移都是在general view下進行的，這時可以不必關心view的owner。在建立View時要注意一定要將View建立為Dynamic View，并映射為本地的一個盤符，在稍后的操作中所有的操作都是以命令行方式進行。

3.4 備份要遷移的VSS配置庫到VOB所在的機器
備份的目錄主要是可以根據遷移的需要對目錄進行修改，而不會影響VSS配置庫，所有的遷移的操作都是針對備份到VOB所在機器的配置庫進行的。

3.5 設置VSS的工程目錄
進行命令行模式，執行ss cp獲得當前的工程目錄，如果不是要遷移的目錄執行ss cp $/要遷移的目錄/，注意這時遷移的是當前目錄的子目錄，如果想包括當前目錄，請到當前目錄的上一級目錄，這時如果只想備份上一級目錄的部分子目錄可以將其他目錄刪除，這時就可以看到用備份的VSS配置庫進行操作的好處了。

3.6 生成遷移所需要的文件
VSS的工程目錄確定后，執行clearexport_ssafe -r -o生成遷移所需要的文件。例：

Clearexport_ssafe -r -o e:\test\exportdata

3.7 遷移
進入general view所對應的映射盤，進入VOB所在的目錄，如VOB名為Test_VOB，general view映射為Y盤，則cd y:

cd \Test_VOB

確定是否遷移到當前目錄，如果要建立子目錄要注意，用命令行建立的子目錄實際并沒有在VOB中建立，要在Rational explorer中建立子目錄，并確認子目錄的類型為Directory Element才可以。

進入要遷移的目錄后執行clearimport e:\test\exportdata，注意如果是java等代碼要區分大小寫，要加參數clearimport -pcase e:\testexportdata

3.8 后續步驟
將當前數據遷入后打一個label，并Apply；將VOB或其子目錄Import為Component，而后在Component上執行Import Baseline，將剛打的label引入即可。