Lagerresurshantering

När du har skapat en RepositoryProvider, finns ytterligare resurshanteringsmekanismer som du behöver känna till:

Ignorerade filer

I flera fall kan det vara onödigt att behålla vissa filer under lagerstyrning.  Resurser som t.ex. hämtas från befintliga resurser kan oftast uteslutas i lagret.  Exempelvis kan kompilerade källfiler (t.ex. Java ".class"-filer) uteslutas eftersom deras motsvarande källa (".java")-filen finns i lagret.  Det kan också vara olämpligt att versionsstyra metadatafiler som skapas av lagerproviders.  Med utökningspunkten org.eclipse.team.core.ignore kan providers deklarera filtyper som ska ignoreras för åtgärder i lagerprovidern.  Exempelvis deklarerar CVS-klienten följande:

<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>

Märkningen deklarerar helt enkelt ett filnamn mönster som bör ignoreras och ett valt attribut som deklarerar standardurvalsvärde för filtypen i dialogrutan för egenskaper.  Det är användaren som bestämmer vilka filer som ska ignoreras.  Användaren kan markera, avmarkera, lägga till eller ta bort filtyper i standardlistan över ignorerade filer.

Filtyper

I vissa lager implementeras olika hantering av textfiler och binära filer.  Utökningen org.eclipse.team.core.fileTypes kan användas så att insticksprogram kan deklarera filtyper som text eller binära filer.  Java-verktygen deklarerar t.ex. följande:

<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>

Med hjälp av märkningen kan insticksprogrammen definiera en filtyp med tillägg och tilldela typ text eller binär.  Precis som med ignorerade filer kan användaren hantera listan över textfiltyper och binära filtyper.

Grupp och länkade resurser

Ett projekt kan innehålla resurser som inte finns i projektets katalog i det lokala filsystemet. Dessa resurser kallas för länkade resurser.

Konsekvenser för lagerproviders

Länkade resurser kan ge speciella utmaningar för lagerproviders som arbetar direkt mot filsystemet. Detta är en konsekvens av det faktum att länkade resurser till sin natur inte finns i projektets omedelbara katalogträd i filsystemet.

Providers, med följande egenskaper, kan påverkas av länkade resurser:

  1. De som anropar ett externt program som sedan körs direkt mot filsystemet.
  2. De som implementeras i termer av IResource men antar att alla filerna/mapparna i ett projekt är direkt underordnade detta enda rotkatalogträd.

I det första fallet antar vi att användaren tar en länkad resurs och försöker utföra en provideråtgärd. Eftersom providern anropar en kommandoradsklient kan vi anta att providern gör något som motsvarar att först anropa IResource.getLocation().toOSString(), och ange resulterande filsystemsplats som ett argument till kommandoradsprogrammet. Om den aktuella resursen är en länkad resurs ger detta en fil/mapp utanför projektets katalogträd. Det är inte alla kommandoradsklienter som kan förvänta sig och har möjlighet att hantera ett sådant fall. Kort sagt, om providern någonsin får en filsystemsplats från en resurs krävs troligen extraarbete för hantering av länkade resurser.

Det andra fallet liknar det första på så sätt att det finns ett underförstått antagande att projektresursernas struktur helt matchar filsystemets filer/mappar. I allmänhet kan en provider få problem om IResource- och java.io.File-åtgärderna blandas. För länkar är t.ex. det överordnade objektet till IFile inte detsamma som överordnat objekt för java.io.File. Kod som antar att dessa är desamma kommer att misslyckas.

Bakåtkompatibilitet

Det var viktigt att introduktionen av länkade resurser inte av misstag bryter befintliga providers. Bekymret var specifikt providers som rimligt antog att den lokala filsystemstrukturen speglade projektstrukturen. Följaktligen kan länkade resurser som standard inte läggas till i projekt som avbildas till en sådan provider. Dessutom kan projekt, som innehåller länkade resurser, inte som standard delas med den providern.

Strategier för hantering av länkade resurser

I syfte att vara "länkvänlig" bör en provider tillåta att projekt med länkade resurser versionskontrolleras men kan neka versionskontroll av själva de länkade resurserna.

En avsevärt mer komplex lösning skulle vara att tillåta versionshantering av de faktiska länkade resurserna men detta ska inte uppmuntras eftersom det medför komplexa situationer (filen kanske exempelvis redan har versionkontrollerats under ett annat projektträd, av en annan provider). Vår rekommendation är därför att stödja versionskontrollerade projekt som innehåller icke-versionskontrollerade länkade resurser.

Teknisk information för att vara "länkvänlig"

Implementationer av lagerproviders kan uppgraderas för att stödja länkade resurser genom att åsidosätta RepositoryProvider.canHandleLinkedResources()-metoden för att returnera true. När detta har gjorts kan det finnas länkade resurser i projekt som delas med den lagerprovidern. Lagerprovidern måste däremot vidta åtgärder för att säkerställa att länkade resurser hanteras på rätt sätt. Som nämnts ovan rekommenderar vi att lagerproviders ignorerar alla länkade resurser. Det innebär att länkade resurser (och underordnade objekt) bör uteslutas från de åtgärder som stöds av lagerprovidern. Dessutom bör lagerprovidern använda standardbeteende för flytta/ta bort av länkade resurser om implementationen av lagerprovidern åsidosätter standarden IMoveDeleteHook.

Grupproviders kan använda IResource.isLinked() för att bestämma om en resurs är en länk. Den här metoden returnerar emellertid bara "true" för roten på en länk. Följande kodsegement kan användas till att bestämma om en resurs är ett underordnat objekt till en länk.

String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();

Lagerproviders bör ignorera alla resurser för vilka ovanstående kod returnerar true.

Grupprivata resurser

Det är vanligt att lagerimplementationer använder extrafiler och mappar för att lagra information som är specifik för lagerimplementationen.  Även om dessa filer kan behövas på arbetsytan är de inte intressanta för andra insticksprogram eller för slutanvändaren.

Grupproviders kan använda IResource.setTeamPrivateMember(boolean) och indikera att en resurs är privat för implementationen av en grupprovider. Nyligen skapade resurser är inte privata medlemmar som standard så metoden måste användas till att uttryckligen markera resursen som grupprivat.  Det är vanligt att markera en undermapp till projektet som grupprivat när projektet konfigureras för gruppen och undermappen skapas.

Andra resurs-API:er som räknar upp resurser (t.ex. resursdeltaträd) undantar grupprivata medlemmar, om det inte uttryckligen begärs att de ska tas med.  Det innebär att de flesta klienterna inte "ser" grupprivata resurser och de visas inte för användaren.  Resursnavigatören visar som standard inte privata medlemmar men användare kan via Egenskaper indikera att de vill se grupprivata resurser.

Försök att märka projekt eller arbetsyterot som grupprivat ignoreras.

Projektuppsättningar

Eftersom resurserna i ett projekt under versionskontroll behålls i lagret är det möjligt att dela projekt med gruppmedlemmar genom att dela en referens till den lagerspecifika information som behövs för att rekonstruera ett projekt i arbetsmiljön.  Detta görs med en speciell typ av filexport för grupprojektuppsättningar.  

 

I 3.0 lades ett API till i ProjectSetCapability som låter lagerproviders deklarera en klass som implementerar projektsparande av projekt som de hanterar.  När användaren väljer att exportera projektuppsättningar visas bara projekt, konfigurerade med lager som definierar projektuppsättningar, som kandidater för exporten. Med det här API:t ersätts API:t för serialisering av gamla projekt ( se nedan).

Funktionsklassen för projektuppsättningen för en lagerprovider erhålls från klassen RepositoryProviderType som registreras i samma utökning som lagerprovidern. Exempel:

<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>

Före 3.0 tillät utökningspunkten org.eclipse.team.core.projectSets att lagerproviders deklarerade en klass som implementerar projektsparande för projekt som de hanterar.  När användaren väljer att exportera projektuppsättningar visas bara projekt, konfigurerade med lager som definierar projektuppsättningar, som kandidater för exporten.

Exempelvis deklarerar CVS-klienten följande:

<extension point="org.eclipse.team.core.projectSets">
<projectSets id="org.eclipse.team.cvs.core.cvsnature" class="org.eclipse.team.internal.ccvs.ui.CVSProjectSetSerializer"/>
</extension>

Angiven klass måste implementera IProjectSetSerializer. Användning av gränssnittet hanteras fortfarande i 3.0 men har utkommenterats.