一旦您建立了 RepositoryProvider,
應該還要瞭解其他的資源管理機制︰
在某些情況下,可能不需要在儲存庫的控制之下來保存某些檔案。例如,從現有資源衍生出來的資源通常會被儲存庫忽略。比如說, 可以忽略已編譯的程式檔(如 Java ".class" 檔),因為儲存庫中有對應的程式 (".java") 檔案。儲存庫提供者所產生的版本控制 meta 資料可能也不適合。org.eclipse.team.core.ignore 延伸點允許提供者宣告儲存庫提供者作業應該忽略的檔案類型。例如,CVS 用戶端宣告下列:
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
標記簡單宣告了系統不處理的檔案名稱型樣,而且在喜好設定對話框中宣告了檔案類型預設選項的已選取屬性。最後根據使用者的需求來決定系統不處理那些檔案。使用者可能從忽略的預設檔案清單中選取、取消選取、新增或刪除檔案類型。
某些儲存庫為文字檔及二進位檔實作不同的處理。org.eclipse.team.core.fileTypes 延伸讓外掛程式宣告檔案類型為文字檔或二進位檔。例如,Java 工具宣告下列檔案類型:
<extension point="org.eclipse.team.core.fileTypes">
<fileTypes extension="java" type="text"/>
<fileTypes extension="classpath" type="text"/>
<fileTypes extension="properties" type="text"/>
<fileTypes extension="class" type="binary"/>
<fileTypes extension="jar" type="binary"/>
<fileTypes extension="zip" type="binary"/>
</extension>
標記讓外掛程式利用副檔名定義檔案類型並指定文字檔或二進位檔的類型。關於忽略的檔案,最後看使用者怎麼管理文字檔和二進位檔案類型的清單。
一個專案可能含有不在本端檔案系統中專案目錄內的資源。 這些資源稱為鏈結資源。
鏈結資源可以對儲存庫提供者造成直接對檔案系統操作的特別盤查。 這是因為在設計上鏈結資源並不存在於檔案系統中的目前專案目錄樹內。
顯出下列性質的提供者可能會受到鏈結資源的影響:
在第一種情況下,讓我們假設使用者挑選一個鏈結資源,然後嘗試對它執行一個提供者作業。 既然提供者會呼叫指令行用戶端,則我們假設提供者的確會做出等同於第一次呼叫 IResource.getLocation().toOSString(), 的動作,將產生的檔案系統位置當作引數饋送至指令行程式。如果有問題的資源是鏈結資源, 這將在專案目錄樹外面產生一個檔案/資料夾。並非所有指令行用戶端都可以期待, 且能夠處理這種情況。簡言之,如果您的提供者曾經取得資源的檔案系統位置, 它將有可能需要額外的工作,才能處理鏈結資源。
第二種情況相當類似,因為有一個隱含的假設,指出專案資源的結構與檔案系統檔案/資料夾的結構是 1:1。通常,如果它們混合 IResource 和 java.io.File 作業,提供者可能會有麻煩。 舉例來說,對於鏈結, IFile 的母項不同於 java.io.File 的母項,因此假設這兩者相同的程式碼將失敗。
引進鏈結資源並非故意毀壞現有的提供者,這點很重要。 尤其,提供者在意的是,合理地假設本端檔案系統結構已鏡映專案結構。 因此,依預設,鏈結資源無法新增至已對映至如此提供者的專案。 此外,依預設,含有鏈結資源的專案無法與該提供者共用。
為了能夠「易於鏈結」,提供者應該容許具有鏈結資源的專案受到版本控制,但是不容許以版本控制鏈結資源本身。
更加複雜的解決方案將容許把實際的鏈結資源版本化,但不應該鼓勵這樣做,因為它會帶來更複雜的情況(如檔案可能已在不同的專案樹下,受到另一個提供者的版本控制)。因此,我們的建議是支援版本控制的專案, 但它們必須含有非版本控制的鏈結資源。
儲存庫提供者實作可以升級,以支援鏈結資源, 方法為置換 RepositoryProvider.canHandleLinkedResources() 方法以傳回 true。一旦這樣做, 將容許鏈結資源存在於與該儲存庫提供者共用的專案中。然而, 儲存庫提供者必須採取若干步驟,以確定適當處理鏈結資源。 如同上面所提,強烈建議儲存庫提供者忽略所有鏈結資源。 這表示鏈結資源(及其子項)應該從儲存庫提供者支援的動作排除。 此外,如果儲存庫提供者實作置換了預設 IMoveDeleteHook, 則儲存庫提供者應該對鏈結資源使用預設移動和刪除行為。
團隊提供者可以使用 IResource.isLinked() ,來判定資源是否為鏈結。然而,這種方法僅會對鏈結的根目錄傳回 True。 下列程式碼區段可用來判定資源是否為鏈結的子項。
String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();
儲存庫提供者應該忽略任何被上面程式碼評估為 true 的資源。
對儲存庫實作來說,使用額外檔案和資料夾來儲存關於儲存庫實作的資訊是常見的。雖然這些檔案可能為工作區所需,但對其他外掛程式和一般使用者是無用的。
團隊提供者可能使用 IResource.setTeamPrivateMember(boolean) 來表示資源對團隊提供者的實作是私密的。 新建的資源依預設不是私密成員,所以必須使用方法來明確地標記資源為團隊私密。一般用法是在為團隊配置專案和建立子資料夾時,標記專案的子資料夾為團隊私密。
會列舉資源的其他資源 API(比如說,資源差異樹狀結構)將會排除團隊私密成員,除非有明確地要求併入。這表示大部分用戶端將不會「看見」團隊私密資源,這些資源也不會顯示給使用者。依預設,資源導覽器不顯示團隊私密成員,但是使用者能夠透過喜好設定指出他們要看見團隊私密資源。
嘗試標記專案或忽略作為團隊私密的工作區根。
在版本控制項下專案中的資源保存在儲存庫中,可能可以藉著跟工作區中重新建構專案分享所需的儲存庫特定的參照並與團隊成員共用專案。使用團隊專案集的特殊檔案匯出類型來完成。
在 3.0 中,API 會加入 ProjectSetCapability, 以容許儲存庫提供者宣告控制項下為專案儲存實作專案的類別。使用者選擇匯出專案集,只有與定義專案集的儲存庫進行了配置的專案會 顯示為候選的匯出專案集。這個 API 取代舊的專案集序列化 API(請參閱以下)。
儲存庫提供者的專案集功能類別是從 RepositoryProviderType 類別取得, 這個類別是登錄在與儲存庫提供者相同的延伸之中。例如:
<extension point="org.eclipse.team.core.repository">
<repository
typeClass="org.eclipse.team.internal.ccvs.core.CVSTeamProviderType"
class="org.eclipse.team.internal.ccvs.core.CVSTeamProvider"
id="org.eclipse.team.cvs.core.cvsnature">
</repository>
</extension>
在 3.0 之前,org.eclipse.team.core.projectSets 延伸點容許儲存庫提供者宣告控制項下為專案儲存實作專案的類別。 使用者選擇匯出專案集,只有與定義專案集的儲存庫進行了配置的專案會 顯示為候選的匯出專案集。
例如,CVS 用戶端宣告下列:
<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>
特定的類別必須實作 IProjectSetSerializer。在 3.0 中仍支援使用這個介面,但是已即將棄用。