Po utworzeniu klasy RepositoryProvider należy poznać inny dostępny mechanizm zarządzania zasobami.
W kilku przypadkach utrzymywanie pewnych plików pod kontrolą repozytorium może być niepotrzebne. Na przykład zasoby pochodzące od istniejących zasobów mogą być często poza repozytorium. Dotyczy to chociażby skompilowanych plików źródłowych (takich jak pliki ".class" języka Java), które nie muszą być przechowywane w repozytorium, ponieważ są tam już odpowiadające im pliki źródłowe (".java"). Nieodpowiednie może być także stosowanie kontroli wersji do plików metadanych generowanych przez dostawców repozytorium. Punkt rozszerzenia org.eclipse.team.core.ignore umożliwia dostawcom deklarowanie typów plików, które powinny być ignorowane w operacjach dostawcy repozytorium. Na przykład klient CVS zawiera deklaracje:
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
W tym kodzie znaczników deklarowany jest po prostu wzorzec (pattern) nazw plików, które powinny być ignorowane, oraz atrybut selected, który deklaruje domyślne zaznaczenie wartości tego typu pliku w oknie dialogowym preferencji. Ostateczna decyzja co do tego, które pliki powinny być ignorowane, należy do użytkownika. Użytkownik może zaznaczać typy plików, anulować ich zaznaczenie oraz usuwać je z listy domyślnie ignorowanych plików.
Niektóre repozytoria definiują różną obsługę plików tekstowych i plików binarnych. Rozszerzenie org.eclipse.team.core.fileTypes umożliwia deklarowanie przez moduły dodatkowe typów plików jako binarnych lub tekstowych. Na przykład pakiet narzędzi języka Java zawiera następujące deklaracje:
<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>
Ten kod znaczników pozwala modułom dodatkowym deklarować typ pliku według rozszerzenia (extension) i przypisywać mu typ (type) tekstowy lub binarny. Podobnie jak w przypadku plików ignorowanych, ostateczna decyzja co do tego, które pliki powinny być ignorowane, należy do użytkownika.
Projekt może zawierać zasoby, które znajdują się poza katalogiem projektu w lokalnym systemie plików. Zasoby te określa się mianem zasobów dowiązanych.
Zasoby dowiązane mogą stawiać konkretne wyzwania przed dostawcami repozytorium, którzy działają bezpośrednio w odniesieniu do systemu plików. Jest to konsekwencją faktu, że zasobów dowiązanych, zgodnie z ich naturą, nie ma w natychmiastowym drzewie katalogu projektu w systemie plików.
Zasoby dowiązane mogą mieć niekorzystny wpływ na dostawców wykazujących następujące cechy:
W pierwszym przypadku można przyjąć, że użytkownik wybiera zasób dowiązany i próbuje wykonać na nim operację dostawcy. Ponieważ dostawca wywołuje klienta wiersza komend, przyjmuje się, że dostawca robi coś odpowiadającego wywołaniu najpierw metody IResource.getLocation().toOSString() i użyciu zwróconego położenia w systemie plików jako argumentu programu wiersza komend. Gdy dany zasób jest zasobem dowiązanym, metoda ta dostarczy plik/folder leżący poza drzewem katalogu projektów. Nie każdy klient wiersza komend może tego oczekiwać i umieć obsłużyć taki przypadek. Mówiąc krótko, gdy dany dostawca kiedykolwiek pobiera położenie zasobu w systemie plików, najprawdopodobniej będzie musiał wykonać dodatkową pracę, aby obsłużyć zasoby dowiązane.
Drugi przypadek jest całkiem podobny, gdyż w sposób jawny zakłada się w nim, że struktura zasobów projektu jest odwzorowaniem plików/folderów systemu plików w stosunku 1:1. W ogólności dostawca mógłby mieć problem w przypadku mieszanych operacji IResource i java.io.File. Na przykład dla dowiązań element nadrzędny obiektu IFile nie jest tym samym, co element nadrzędny operacji java.io.File, a wykonanie kodu, który zakładałby równoważność, nie powiedzie się.
Istotną kwestią w momencie wprowadzania zasobów dowiązanych było to, aby niechcąco nie spowodowały one błędów w działaniu istniejących dostawców. W szczególności dotyczyło to dostawców, dla których racjonalnie przyjęto, że lokalny system plików odzwierciedla strukturę projektu. W rezultacie domyślnie nie można dodawać zasobów dowiązanych do projektów odwzorowanych na takiego dostawcę. Dodatkowo, projekty zawierające zasoby dowiązane domyślnie nie mogą być współużytkowane z takim dostawcą.
Aby dostawca był "przyjazny dla dowiązań", powinien umożliwiać kontrolę wersji dla projektów z zasobami dowiązanymi, ale może wykluczać kontrolę wersji samych zasobów dowiązanych.
Znacznie bardziej złożonym rozwiązaniem byłoby umożliwienie kontroli wersji rzeczywistych zasobów dowiązanych, jednak należy to odradzać, ponieważ może to skutkować koniecznością brania pod uwagę skomplikowanych scenariuszy (np. plik może już podlegać kontroli wersji w drzewie innego projektu przez innego dostawcę). Dlatego zaleca się obsługę projektów podlegających kontroli wersji, które zawierają zasoby dowiązane niepodlegające kontroli wersji.
Implementacje dostawców repozytorium można zaktualizować w celu obsługi zasobów dowiązanych, przesłaniając metodę RepositoryProvider.canHandleLinkedResources() w taki sposób, aby zwracała wartość true.Dzięki temu zasoby dowiązane będą mogły istnieć w projektach współużytkowanych przez tego dostawcę repozytorium. Jednak dostawca repozytorium musi jeszcze przedsiębrać kroki zapewniające poprawną obsługę zasobów dowiązanych. Jak wspomniano wcześniej, usilnie zaleca się, aby dostawcy repozytoriów ignorowali wszystkie zasoby dowiązane. Oznacza to, że zasoby dowiązane (i ich elementy podrzędne) powinny być wyłączone z akcji obsługiwanych przez dostawcę repozytorium. Co więcej, dostawca repozytorium powinien używać domyślnego zachowania dla operacji przenoszenia i usuwania zasobów dowiązanych, gdy implementacja dostawcy repozytorium przesłania domyślną klasę IMoveDeleteHook.
W celu określenia, czy dany zasób jest dowiązany, dostawcy repozytorium mogą używać metody IResource.isLinked(). Jednak metoda ta zwraca wartość true tylko dla elementu głównego dowiązania. W celu określenia, czy dany zasób jest elementem podrzędnym dowiązania można użyć poniższego fragmentu kodu.
String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();
Dostawcy repozytoriów powinni ignorować wszelkie zasoby, dla których powyższy kod zwraca wartość true.
Typowe dla implementacji dostawców jest korzystanie z dodatkowych plików i folderów w celu przechowywania informacji dotyczących implementacji repozytorium. Chociaż te pliki mogą być potrzebne w obszarze roboczym, nie mają one znaczenia dla innych modułów dodatkowych ani dla użytkownika końcowego.
Aby wskazać, że dany zasób jest prywatnym zasobem implementacji dostawcy zespołowego, dostawcy zespołowi mogą używać metody IResource.setTeamPrivateMember(boolean). Nowo utworzone zasoby nie są domyślnie traktowane jako prywatne, dlatego konieczne jest użycie tej metody w celu jawnego oznaczenia zasobu jako prywatnego dla zespołu. Typowym zastosowaniem jest oznaczenie podfolderu projektu jako prywatnego dla zespołu, gdy projekt zostanie skonfigurowany jako zespołowy i zostanie utworzony podfolder.
Inne interfejsy API zasobów, które wyliczają zasoby (takie jak drzewa wartości delta zasobów) będą wykluczać elementy prywatne dla zespołów, o ile nie zostanie zażądane w sposób jawny włączenie ich do wyliczenia. Oznacza to, że większość klientów nie będzie "widzieć" zasobów prywatnych dla zespołów i zasoby te nie będą wyświetlane. Nawigator zasobów domyślnie nie wyświetla prywatnych zasobów zespołów, ale użytkownicy mogą włączyć ich wyświetlanie w preferencjach.
Próba oznaczenia projektów lub elementu głównego obszaru roboczego jako prywatnych zostanie zignorowana.
Ponieważ zasoby projektu podlegającego kontroli wersji są przechowywane w repozytorium, członkowie zespołu mogą współużytkować projekty, współużytkując odwołania do informacji właściwych dla repozytorium, które są potrzebne do zrekonstruowania projektu w obszarze roboczym. Można to zrobić, używając dla zbiorów projektów zespołu specjalnej operacji eksportu plików.
W wersji 3.0, do klasy ProjectSetCapability dodano interfejs API, aby umożliwić dostawcom repozytorium zadeklarowanie klasy, która implementuje operację zapisywania projektów kontrolowanych przez tych dostawców. Gdy użytkownik zdecyduje się wyeksportować zbiory projektów, na liście projektów dostępnych do wyeksportowania zostaną wyświetlone tylko projekty powiązane z repozytoriami, które definiują zbiory projektów. Ten interfejs API zastępuje stary interfejs API szeregowania zbiorów projektów (patrz niżej).
Klasa możliwości zbioru projektów dla dostawcy repozytorium jest uzyskiwana z klasy RepositoryProviderType zarejestrowanej w tym samym rozszerzeniu, co dostawca repozytorium. Na przykład:
<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>
Przed wersją 3.0 punkt rozszerzenia org.eclipse.team.core.projectSets umożliwiał dostawcom repozytorium deklarowanie klasy implementującej operację zapisywania projektów kontrolowanych przez tych dostawców. Gdy użytkownik zdecyduje się wyeksportować zbiory projektów, na liście projektów dostępnych do wyeksportowania zostaną wyświetlone tylko projekty powiązane z repozytoriami, które definiują zbiory projektów.
Na przykład klient CVS zawiera następujące deklaracje:
<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>
Określona klasa musi implementować interfejs IProjectSetSerializer. Użycie tego interfejsu jest w dalszym ciągu obsługiwane w wersji 3.0, ale zostało oznaczone jako nieaktualne.