Správa prostředků úložiště

Po vytvoření třídy RepositoryProvider je zapotřebí pochopit další mechanizmy správy prostředků:

Ignorované soubory

V některých případech může být nezbytné ponechat určité soubory pod kontrolou úložiště.  Například prostředky odvozené od existujících prostředků lze často z úložiště vynechat.  Například lze vynechat kompilované zdrojové soubory (jako např. soubory ".class" prostředí Java), neboť jejich odpovídající zdrojový soubor (".java") je v úložišti.   Rovněž nemusí být vhodné spravovat verze u souborů metadat, které generují poskytovatelé úložiště.  Bod rozšíření org.eclipse.team.core.ignore umožňuje poskytovatelům deklarovat typy souborů, které by měly být z pohledu operací poskytovatele úložiště ignorovány.  Například klient CVS deklaruje následující:

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

Tento markup jednoduše deklaruje vzor názvu souboru, který by měl být ignorován, a atribut selected (vybraný), jenž deklaruje výchozí hodnotu volby typu souboru v dialogovém okně předvoleb.  Na uživateli je pak konečné rozhodnutí o tom, které soubory by se měly ignorovat.  Uživatel může ve výchozím seznamu ignorovaných souborů vybírat typy souborů, rušit jejich výběr, přidávat je, nebo je odstraňovat.

Typy souborů

Některá úložiště implementují rozdílné zacházení s textovými a binárními soubory.  Rozšíření org.eclipse.team.core.fileTypes umožňuje, aby moduly plug-in deklarovaly typy souborů jako textové nebo binární.  Například nástroje Java deklarují následující:

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

Tento markup umožňuje, aby moduly plug-in definovaly typ souboru pomocí přípony a přiřadily typ textový nebo binární.  Podobně jako u ignorovaných souborů je opět na konečném rozhodnutí uživatele, jak bude řídit seznam textových a binárních typů souborů.

Týmové a propojené prostředky

Projekt může obsahovat prostředky, které nejsou umístěny v adresáři projektu na lokálním systému souborů. Tyto prostředky se označují jako propojené prostředky.

Důsledky pro poskytovatele úložišť

Propojené prostředky mohou představovat zvláštní komplikaci pro ty poskytovatele úložišť, kteří pracují přímo se systémem souborů. Jde o důsledek skutečnosti, že propojené prostředky ve své podstatě neexistují v bezprostředním adresářovém stromu projektu v systému souborů.

Propojené prostředky mohou mít vliv na poskytovatele, kteří vykazují následující charakteristiky:

  1. Ty, kteří volají externí program pracující přímo se systémem souborů.
  2. Ty, kteří jsou implementováni v rámci IResource, ale předpokládají, že všechny soubory a složky v projektu existují jako přímé odvozené položky daného adresářového stromu s jedním kořenem.

Předpokládejme, že v prvním uvedeném případě uživatel vybere propojený prostředek a pokusí se nad ním provést operaci poskytovatele. Poskytovatel volá klienta příkazového řádku, a proto můžeme předpokládat, že nejprve bude volat metodu IResource.getLocation().toOSString(), přičemž výsledné umístění systému souborů zadá jako argument programu příkazového řádku. Pokud dotyčný prostředek představuje propojený prostředek, výsledkem bude soubor/složka mimo adresářový strom projektu. Takový vstup může být pro některé klienty příkazového řádku problém a možná jej nebudou schopni zpracovat. Stručně řečeno, pokud váš poskytovatel získá umístění prostředku v systému souborů, pravděpodobně bude nutné věnovat další pozornost zpracování propojených prostředků.

Druhý případ je podobný v tom, že se opět implicitně předpokládá přesná analogie 1:1 mezi strukturou prostředků projektu a soubory/složkami systému souborů. Obecně platí, že pokud poskytovatel volně míchá operace IResource a java.io.File, může se dostat do problémů. Například u odkazů, nadřazený prvek IFile není totožný s nadřazeným prvkem java.io.File a pokud toto některý program předpokládá, dojde k chybě.

Zpětná kompatibilita

Bylo důležité, aby zavedením propojených prostředků nedošlo k nechtěnému narušení stávajících poskytovatelů. Konkrétně se obavy týkaly poskytovatelů, kteří logicky předpokládali, že struktura lokálního systému souborů přesně odráží strukturu projektu. V důsledku toho nelze propojené prostředky standardně přidávat do projektů, které jsou mapovány na takového poskytovatele. Projekty obsahující propojené prostředky dále nemohou být s takovým poskytovatelem sdíleny.

Strategie pro práci s propojenými prostředky

Chce-li poskytovatel zajistit "bezproblémovost propojení", měl by umožnit správu verzí pro projekty s propojenými prostředky, ale zároveň zakázat správu verzí u samotných propojených prostředků.

Výrazně složitějším řešením je umožnit správu verzí u samotných propojených prostředků, ale tento přístup není vhodný, protože v praxi vede na složité scénáře (např. soubor může podléhat správě verzí jiným poskytovatelem v rámci jiného stromu projektu). Doporučujeme proto podporovat projekty se správou verzí, obsahující propojené prostředky bez správy verzí.

Technické podrobnosti pro zajištění bezproblémovosti propojení

Implementace poskytovatelů úložišť lze zdokonalit pro podporu propojených prostředků potlačením metody RepositoryProvider.canHandleLinkedResources(), tak, aby vracela hodnotu true.Pak budou moci propojené prostředky společně existovat v projektech sdílených s takovým poskytovatelem úložiště. Poskytovatel úložiště však musí vykonat kroky pro zajištění toho, že se s propojenými prostředky pracuje správně. Jak již bylo uvedeno výše, důrazně se doporučuje, aby poskytovatelé úložišť všechny propojené prostředky ignorovali. To znamená, že propojené prostředky (a jejich podřízené prvky) by měly být vyloučeny z akcí podporovaných poskytovatelem. Pokud implementace poskytovatele úložiště potlačuje výchozí metodu IMoveDeleteHook, měl by tento poskytovatel dále používat standardní chování operací přesunu a odstraňování u propojených prostředků.

Týmoví poskytovatelé mohou použít metodu IResource.isLinked() ke zjištění, zda je prostředek odkazem. Tato metoda však vrací hodnotu true pouze v případě kořene odkazu. Chcete-li zjistit, zda je prostředek podřízeným prvkem odkazu, můžete použít následující úsek kódu.

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

Poskytovatelé úložišť by měli ignorovat všechny prostředky, pro které výše uvedený kód vrací hodnotu true.

Soukromé týmové prostředky

Implementace úložišť běžně používají další soubory a složky k uložení informací vztahujících se k implementaci úložiště.  Přestože tyto soubory mohou být v pracovním prostoru potřebné, z pohledu jiných modulů plug-in nebo koncových uživatelů jsou nezajímavé.

Týmoví poskytovatelé mohou používat metodu IResource.setTeamPrivateMember(boolean) k označení toho, že prostředek je privátní z pohledu implementace týmového poskytovatele. Nově vytvořené prostředky nejsou standardně soukromé, proto je nutno použít tuto metodu, aby byl prostředek explicitně označen jako soukromý prostředek týmu.  Běžně se jako soukromá označí podsložka projektu v době konfigurace projektu pro tým a vytváření této podsložky.

Další rozhraní API prostředků vytvářející výčet prostředků (jako např. rozdílové stromy prostředků) pak soukromé členské prvky týmu ze seznamu vyloučí, pokud ovšem explicitně nedostanou instrukce, aby je zahrnuly.  To znamená, že většina klientů soukromé prostředky týmu "neuvidí", a tyto nebudou uživateli zobrazeny.   Navigátor prostředků soukromé členské prvky týmu standardně nezobrazuje, ale uživatelé mohou v předvolbách nastavit, že chtěli soukromé prostředky týmu vidět.

Pokusy označit jako projekty nebo kořen pracovního prostoru jako soukromé prvky týmu budou ignorovány.

Sady projektů

Prostředky v rámci projektu se správou verzí jsou ukládány v úložišti, a proto je možné sdílet projekty se členy týmu sdílením odkazu na informace o konkrétním úložišti potřebné k obnovení projektu v pracovním prostoru.  To se provede pomocí zvláštního typu exportu souboru pro týmové sady projektů.  

 

Ve verzi 3.0 bylo přidáno rozhraní API k ProjectSetCapability, aby mohli poskytovatelé úložišť deklarovat třídu implementující ukládání projektů použitelnou na projekty řízené těmito poskytovateli.  Když uživatel zvolí export sad projektů, jako kandidáti pro export se zobrazí pouze projekty nakonfigurované s úložišti, která definují sady projektů. Toto rozhraní API nahrazuje staré rozhraní API pro serializaci sad projektů (viz níže).

Třída podporující sady projektů pro poskytovatele úložišť se získá z třídy RepositoryProviderType, jenž je registrována ve stejném rozšíření jako poskytovatel úložiště. Například:

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

Před verzí 3.0 umožňoval bod rozšíření org.eclipse.team.core.projectSets poskytovatelům úložišť deklarovat třídu, která implementuje ukládání projektů použitelné pro projekty řízené těmito poskytovateli.  Když uživatel zvolí export sad projektů, jako kandidáti pro export se zobrazí pouze projekty nakonfigurované s úložišti, která definují sady projektů.

Například klient CVS deklaruje následující:

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

Zadaná třída musí implementovat IProjectSetSerializer. Toto rozhraní je ve verzi 3.0 stále podporováno, ale nyní je již nepřípustné.