Ressourcestyring på opbevaringssted

Når du har oprettet en RepositoryProvider, er der andre ressourcestyringsmekanismer, som du bør have kendskab til:

Ignorerede filer

I mange tilfælde kan det være unødvendigt at holde bestemte filer under opbevaringsstedskontrol. Ressourcer, der er afledt af eksisterende ressourcer, kan f.eks. ofte udelades fra opbevaringsstedet. Kompilerede kildefiler, f.eks. Java-klassefiler (".class"), kan eksempelvis udelades, da deres tilsvarende kildefil (".java") befinder sig på opbevaringsstedet. Det kan også være irrelevant at versionskontrollere metafiler, der genereres af udbydere af opbevaringssteder. Med udvidelsespunktet org.eclipse.team.core.ignore kan udbydere erklære filtyper, der skal ignoreres ved funktioner, der vedrører udbydere af opbevaringssteder. CVS-klienten erklærer f.eks. følgende:

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

Denne kode erklærer ganske enkelt et filnavnemønster, der skal ignoreres, og en valgt attribut, som erklærer standardvalgværdien af filtypen i indstillingsdialogboksen. I sidste ende er det op til brugeren at beslutte, hvilke filer der skal ignoreres. Brugeren kan vælge, fravælge eller slette filtyper på standardlisten over ignorerede filer.

Filtyper

Nogle opbevaringssteder implementerer forskellig håndtering for tekst- og binære filer. Udvidelsen org.eclipse.team.core.fileTypes gør det muligt for plugins at erklære filtyper som tekst- eller binære filer. Java-værktøjet erklærer f.eks. følgende:

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

Koden giver plugins mulighed for at definere en filtype efter udvidelse og tildele typen tekst eller binær. Som med ignorerede filer er det i sidste ende op til brugeren at administrere listen over tekst- og binære filtyper.

Team og sammenkædede ressourcer

Et projekt kan indeholde ressourcer, der ikke findes i projektets bibliotek på det lokale filsystem. Disse ressourcer kaldes sammenkædede ressourcer.

Konsekvenser for udbydere af opbevaringssteder

Sammenkædede ressourcer kan udgøre særlige udfordringer for udbydere af opbevaringssteder, som arbejder direkte med filsystemet. Dette er konsekvensen af, at sammenkædede ressourcer i henhold til deres design ikke findes i projektets direkte bibliotekstræstruktur i filsystemet.

Udbydere, som har følgende egenskaber, kan blive påvirket af sammenkædede ressourcer:

  1. De, der kalder et eksternt program, som derefter arbejder direkte op mod filsystemet.
  2. De, som implementeres med hensyn til IResource, men som antager, at alle filer/foldere i et projekt findes som direkte underordnede til den pågældende bibliotekstræstruktur med enkelt rod.

Lad os i det første tilfælde antage, at brugeren henter en sammenkædet ressource og forsøger at udføre en udbyderfunktion på den. Eftersom udbyderen kalder en kommandolinjeklient, kan vi antage, at udbyderen gør noget, der svarer til først at kalde IResource.getLocation().toOSString() og anvender den resulterende placering i filsystemet som argument for kommandolinjeprogrammet. Hvis den pågældende ressource er en sammenkædet ressource, bliver resultatet en fil/folder uden for projektets bibliotekstræstruktur. Ikke alle kommandolinjeklienter kan forvente og være i stand til at håndtere dette tilfælde. Kort sagt, hvis udbyderen nogen sinde henter en ressources placering i filsystemet, vil det sandsynligvis kræve ekstra arbejde at håndtere sammenkædede ressourcer.

Det andet tilfælde ligner meget, idet der ligger en implicit antagelse om, at strukturen af projektressourcerne er 1:1 med strukturen i filsystemets filer/foldere. Generelt kan en udbyder få problemer, hvis funktionerne IResource og java.io.File blandes. Ved link er den overordnede til IFile f.eks. ikke den samme som den overordnede til java.io.File, og kode, som antager, at disse er ens, vil ikke fungere korrekt.

Bagudkompatibilitet

Det er vigtigt, at introduktionen af sammenkædede ressourcer ikke utilsigtet blokerer for eksisterende udbydere. Særligt har hensynet til udbydere, som med rimelighed antog, at strukturen af det lokale filsystem afspejlede projektstrukturen, vejet tungt. Derfor kan sammenkædede ressourcer som standard ikke tilføjes til projekter, der er tilknyttet til en sådan udbyder vha. mapping. Desuden kan projekter, som indeholder sammenkædede ressourcer, som standard ikke deles med denne udbyder.

Strategier for håndtering af sammenkædede ressourcer

For at være "sammenkædningsvenlig" skal en udbyder tillade projekter med sammenkædede ressourcer at blive versionskontrolleret, men kan undlade at tillade versionskontrol af selve de sammenkædede ressourcer.

En betydeligt mere kompleks løsning kunne være at tillade versionering af de faktiske sammenkædede ressourcer, men dette kan ikke anbefales, da det medfører komplekse scenarier, f.eks. kan filen allerede være versionskontrolleret under en anden projekttræstruktur af en anden udbyder. Det er vores anbefaling at understøtte versionskontrollerede projekter, som indeholder ikke-versionskontrollerede sammenkædede ressourcer.

Tekniske oplysninger om "sammenkædningsvenlighed"

Udbydere af opbevaringssteder kan opgraderes til at understøtte sammenkædede ressourcer ved at tilsidesætte metoden RepositoryProvider.canHandleLinkedResources(), så den returnerer true. Når det er gjort, vil sammenkædede ressourcer kunne eksistere i projekter, der deles med denne udbyder af opbevaringssteder. Men udbyderen af opbevaringssteder skal træffe forholdsregler for at sikre, at sammenkædede ressourcer behandles korrekt. Som nævnt ovenfor, anbefales det kraftigt, at udbydere af opbevaringssteder ignorerer alle sammenkædede ressourcer. Det betyder, at sammenkædede ressourcer og deres underordnede skal udelukkes fra funktioner, der understøttes af udbyderen af opbevaringssteder. Desuden skal udbyderen af opbevaringssteder anvende standardfunktionsmåden for flytning og sletning til sammenkædede ressourcer, hvis implementeringen af udbyderen af opbevaringssteder tilsidesætter standard-IMoveDeleteHook.

Teamudbydere kan bruge IResource.isLinked() til at afgøre, om en ressource er et link. Men denne metode returnerer kun true for roden af et link. Følgende kodesegment kan bruges til at afgøre, om en ressource er underordnet til et link.

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

Udbydere af opbevaringssteder bør ignorere en ressource, hvor ovenstående kode evalueres til true.

Teamprivate ressourcer

Det er almindeligt for implementeringer af opbevaringssteder at bruge ekstra filer og foldere til at gemme oplysninger, som er specifikke for opbevaringsstedsimplementeringen. Selvom disse filer kan være nødvendige i arbejdsområdet, er de ikke interessante for andre plugins eller for slutbrugeren.

Teamudbydere kan bruge IResource.setTeamPrivateMember(boolean) til at angive, at en ressource er privat for implementeringen af en teamudbyder. Nye ressourcer er ikke som standard private medlemmer, så denne metode skal bruges til eksplicit at markere en ressource som teamprivat. En almindelig anvendelse er at markere en underfolder af projektet som teamprivat, når projektet konfigureres til team, og underfolderen oprettes.

Andre ressource-API'er, der opregner ressourcer (f.eks. ressourcedelta-træstrukturer), udelukker teamprivate medlemmer, medmindre de eksplicit bliver anmodet om at inkludere dem. Det betyder, at de fleste klienter ikke "ser" de teamprivate ressourcer, og at de ikke bliver vist for brugeren. Ressourcenavigatoren viser ikke teamprivate medlemmer som standard, men brugerne kan angive via Indstillinger, at de gerne vil se teamprivate ressourcer.

Forsøg på at markere projekter eller arbejdsområderoden som teamprivate bliver ignoreret.

Projektsæt

Eftersom ressourcer i et projekt under versionskontrol opbevares på opbevaringsstedet, er det muligt at dele projekter med teammedlemmer ved at dele en reference til opbevaringsstedsspecifikke oplysninger, der er nødvendige for at genopbygge et projekt i arbejdsområdet. Det gøres vha. en særlig type fileksport for teamprojektsæt.  

 

I 3.0 blev API tilføjet til ProjectSetCapability for at tillade udbydere af opbevaringssteder at erklære en klasse, der implementerer projektlagring for projekter under deres kontrol. Når brugeren vælger at eksportere projektsæt, vises kun de projekter, der er konfigureret med opbevaringssteder, som definerer projektsæt, som kandidater for eksport. Dette API erstatter det gamle serialiserings-API for projektsæt (se nedenfor).

Muligheden for projektsæt for en udbyder af opbevaringssteder hentes fra klassen RepositoryProviderType, som er registreret i samme udvidelse som udbyderen af opbevaringssteder. Eksempel:

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

Inden 3.0 gav udvidelsespunktet org.eclipse.team.core.projectSets udbydere af opbevaringssteder mulighed for at erklære en klasse, der implementerer projektlagring for projekter under deres kontrol. Når brugeren vælger at eksportere projektsæt, vises kun de projekter, der er konfigureret med opbevaringssteder, som definerer projektsæt, som kandidater for eksport.

CVS-klienten erklærer f.eks. følgende:

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

Den angivne klasse skal implementere IProjectSetSerializer. Brugen af denne grænseflade understøttes i 3.0, men er forældet.