團隊和鏈結資源

一個專案可能含有不在本端檔案系統中專案目錄內的資源。 這些資源稱為鏈結資源

儲存庫提供者的結果

鏈結資源可以對儲存庫提供者造成直接對檔案系統操作的特別盤查。 這是因為在設計上鏈結資源並不存在於檔案系統中的目前專案目錄樹內。

顯出下列性質的提供者可能會受到鏈結資源的影響:

  1. 那些向外呼叫外部程式,再以這個程式直接對檔案系統操作的提供者。
  2. 那些按照 IResource 實作,卻假設專案中的所有檔案/資料夾係以該單一根目錄樹的直接後代存在的提供者。

在第一種情況下,讓我們假設使用者挑選一個鏈結資源,然後嘗試對它執行一個提供者作業。 既然提供者會呼叫指令行用戶端,則我們假設提供者的確會做出等同於第一次呼叫 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 的資源。