A RepositoryProvider
létrehozása után a következő erőforrás-kezelési mechanizmusokat kell
megérteni:
Számos esetben nem szükséges adott fájlokat lerakatvezérlés alatt tartani. A meglévő erőforrásokból származtatott erőforrások például gyakran lekérhetők a lerakatból. A lefordított forrásfájlok (mint a Java ".class" fájlok) például lekérhetők, mivel a megfelelő forrásfájl (".java") megtalálható a lerakatban. Elképzelhető, hogy a lerakatszolgáltatók által előállított metaadat-fájlok verziókövetése nem javasolt. Az org.eclipse.team.core.ignore kiterjesztési pont segítségével a szolgáltatók megadhatják azokat a fájltípusokat, amelyeket a lerakatszolgáltató-műveletek esetén figyelmen kívül kell hagyni. A CVS ügyfél például az alábbit adja meg:
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
A leírónyelv egyszerűen megad egy fájlnévmintát, amelyet figyelmen kívül kell hagyni, egy kiválasztott attribútumot, amely a beállítások párbeszédablakban megadja a fájltípus alapértelmezett választási értékét. Végül a felhasználónak el kell döntenie, hogy mely fájlok legyenek figyelmen kívül hagyva. A felhasználó fájltípusokat törölhet, jelölhet ki vagy megszüntetheti a kijelölést a figyelmen kívül hagyott fájlok alapértelmezett listájában.
Néhány lerakat különböző kezelést vaslósít meg a szöveges illetve bináris fájlokhoz. Az org.eclipse.team.core.fileTypes kiterjesztés segítségével a bedolgozók a fájltípusokat szöveg- vagy bináris fájlként deklarálhatják. A Java eszközkezelés például az alábbit adja meg:
<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>
A leírónyelv segítségével a bedolgozók a fájltípust kiterjesztés alapján adhatják meg, és hozzárendelhetnek egy szöveges vagy bináris típust. A figyelmen kívül hagyott fájlokhoz hasonlóan végül a felhasználó kezeli a szöveges és bináris fájltípusok listáját.
A projekt tartalmazhat olyan erőforrásokat, amelyek nem a projekt könyvtárában találhatók a helyi fájlrendszeren. Ezekre az erőforrásokra csatolt erőforrásokként hivatkozunk.
A csatolt erőforrások kihívásokat támaszthatnak a lerakatszolgáltatókkal szemben, amelyek közvetlenül a fájlrendszeren működnek. Ez annak a következménye, hogy a csatolt erőforrások kialakítás szerint nem léteznek a fájlrendszer közvetlen címjegyzék projektkönyvtárfájában.
Az alábbi jellemzőket mutató szolgáltatókra hatással lehetnek a csatolt erőforrások:
Az első esetben tételezzük fel, hogy a felhasználó kiválaszt egy csatolt erőforrást, és megpróbál végrehajtani rajta egy szolgáltatóműveletet. Mivel a szolgáltató egy parancssori ügyfelet hív meg, feltételezhetjük, hogy a szolgáltató az IResource.getLocation().toOSString(), első meghívásának megfelelő dolgot hajtja végre, az eredményül kapott fájlrendszert pedig a parancssori program argumentumaként biztosítja. Ha a kérdésben szerepelő erőforrás egy csatolt erőforrás, akkor ez a projektkönyvtárfán kívüli fájlt/mappát eredményez. Nem az összes parancssori ügyfél tudja kezelni ezt az esetet. Röviden: ha a szolgáltató megtudja az erőforrás fájlrendszer-helyét, akkor valószínűleg többletmunkát igényel a csatolt erőforrások kezeléséhez.
A második eset nagyon hasonló abban az implicit feltételezésben, hogy a projekt-erőforrások struktúrája 1:1 a fájlrendszer fájljaival/mappáival. Általában a szolgáltató bajba kerülhet, ha keveri az IResource és java.io.File műveleteket. Hivatkozások esetén például az IFile szülője nem egyezik meg a java.io.File szülőjével, és a kód, amely feltételezi ezek egyezését, meghiúsul.
Fontos volt, hogy a csatolt erőforrások bevezetése ne szakítsa meg véletlenül a meglévő szolgáltatókat. A szolgáltatók problémája, hogy érthető módon feltételezték, hogy a helyi fájlrendszer struktúra tükrözte a projektstruktúrát. A csatolt erőforrások alapértelmezésben nem adhatók a projektekhez, amelyek ilyen szolgáltatóra vannak leképezve. A csatolt erőforrásokat tartalmazó projektek alapértelmezés szerint nem oszthatók meg ezzel a szolgáltatóval.
A csatolástámogatás érdekében a szolgáltatóknak engedélyezniük kell a csatolt erőforrásokkal rendelkező projektek verziókövetését, de a csatolt erőforrások verziókövetése letiltható.
Ennél lényegesebben bonyolultabb megoldás az aktuális csatolt erőforrások verziókövetésének engedélyezése, de ez ellenjavallt, mivel összetett példahelyzetekkel jelenik meg (például elképzelhető, hogy a fájl verziókövetését más szolgáltató már megvalósította más projektfa alatt). Javaslatunk a verziókövetett projektek támogatása, amelyek nem verziókövetett csatolt erőforrásokat tartalmaznak.
A lerakatszolgáltató-megvalósítások frissíthetők, hogy támogassák a csatolt erőforrásokat a RepositoryProvider.canHandleLinkedResources() metódus újradefiniálásával, hogy true értéket adjon vissza. Amennyiben ezt megtörtént, a csatolt erőforrások engedélyezettek lesznek a lerakatszolgáltatóval megosztott projektekben. A lerakatszolgáltatónak lépéseket kell tennie annak biztosítása érdekében, hogy a csatolt erőforrások kezelése megfelelően történjen. Ahogy fent említettük, határozottan ajánlott, hogy a lerakatszolgáltatók figyelmen kívül hagyják az összes csatolt erőforrást. Ez azt jelenti, hogy a csatolt erőforrásokat (és leszármazottjaik) ki kell hagyni a lerakatszolgáltató által támogatott tevékenységekből. A lerakatszolgáltatónak az alapértelmezett áthelyezés és törlés viselkedést kell használni a csatolt erőforrásokhoz, ha a lerakatszolgáltató-megvalósítás felülírja az alapértelmezett IMoveDeleteHook csatlakozópontot.
A csapatszolgáltatók az IResource.isLinked() segítségével meghatározhatják, hogy az erőforrás hivatkozás-e. Ez a metódus csak a hivatkozás gyökeréhez ad vissza igaz értéket. Az alábbi kódszegmens segítségével meghatározható, hogy az erőforrás a hivatkozás leszármazottja-e.
String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();
A lerakatszolgáltatóknak figyelmen kívül kell hagyniuk azon erőforrásokat, amelyek esetén a kód értéke true.
A lerakatmegvalósítások általánosan extra fájlokat és mappákat használnak a lerakatmegvalósítás-specifikus információk tárolásához. Ezekre a fájlokra szükség van a munkaterületen, más bedolgozókat vagy végfelhasználókat nem érdekelnek.
A csapatszolgáltatók az IResource.setTeamPrivateMember(boolean) segítségével jelzik, hogy az erőforrás privát a csapatszolgáltató megvalósításához. Az újonnan létrehozott erőforrások alapértelmezés szerint nem privát tagok, így ezt a metódust kell használni az erőforrások csapat privátként megjelöléséhez. Az általános alkalmazás a projekt almappájának csapat privátkénti megjelölése, amikor a csapathoz és almappához létrehozott projekt be van állítva.
Az erőforrásokat (mint például az erőforrás-változásfák) felsoroló más erőforrások kihagyják a csapat privát tagokat, hacsak nincs kifejezetten megadva a tartalmazásuk. Ez azt jelenti, hogy a legtöbb ügyfél nem látja a csapa privát erőforrásokat, és nem jelennek meg más felhasználó számára. Az erőforrás-navigátor alapértelmezés szerint nem jeleníti meg a csapat privát tagokat, de a felhasználók a Beállítások segítségével jelezhetik, hogy szeretnék látni a csapat privát erőforrásokat.
A projekteket vagy munkaterület-gyökér csapat privátként megjelölése figyelmen kívül marad.
Mivel a verziókövetés alatt álló projektek erőforrásai a lerakatban tárolódnak, a projektek a projekt munkaterületen újbóli létrehozásához szükséges lerakatspecifikus információkra mutató hivatkozások megosztásával megoszthatók a csapattagok között. Ez a csapat projekthalmazok speciális fájlexportálás típusával hajtható végre.
A 3.0 verzióban az API hozzáadásra került a ProjectSetCapability elemhez annak engedélyezéséhez, hogy a lerakatszolgáltatók olyan osztályt adjanak meg, amely a projektek mentését a vezérlésük alatt válósítják meg. Ha a felhasználó a projekthalmazok exportálását választják, akkor csak azon lerakatokkal beállított projektek jelennek meg az exportáláshoz jelöltként, amelyek projekthalmazokat határoznak meg.Ez az API helyettesíti a régi projekthalmaz sorbafejtési alkalmazás programozási felületet (lásd alább).
A lerakatszolgáltató projekthalmaz képességosztálya a RepositoryProviderType osztályból kerül lekérésre, amely ugyanabban a kiterjesztésben van bejegyezve, mint a lerakatszolgáltató. Például:
<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>
A 3.0 előtt az org.eclipse.team.core.projectSets kiterjesztési pont lehetővé tette, hogy a szolgáltatók egy olyan osztályt határozzanak meg, amely megvalósítja a projektmentést a vezérlésük alatt álló projektekhez. Ha a felhasználó a projekthalmazok exportálását választják, akkor csak azon lerakatokkal beállított projektek jelennek meg az exportáláshoz jelöltként, amelyek projekthalmazokat határoznak meg.
A CVS ügyfél például az alábbit határozza meg:
<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>
A megadott osztálynak meg kell valósítani az IProjectSetSerializer elemet. Ezen felület használata továbbra is támogatott a 3.0 verzióban, de ez elavult.