Gestione risorse repository

Una volta creato un RepositoryProvider, esistono altri meccanismi di gestione delle risorse che devono essere conosciuti:

File ignorati

In diversi casi, può risultare inutile mantenere determinati file sotto il controllo del repository. Ad esempio, le risorse derivate da risorse esistenti possono spesso essere omesse dal repository. Ciò avviene per i file di origine compilati (ad esempio i file ".class" di Java) che possono essere omessi in quanto il corrispondente file di origine (".java") si trova nel repository. Può inoltre essere inappropriato eseguire il controllo delle versioni dei file di metadati generati dai fornitori di repository. Il punto di estensione org.eclipse.team.core.ignore consente ai fornitori di dichiarare i tipi di file che devono essere ignorati per le operazioni del fornitore di repository. Ad esempio, il client CVS dichiara quanto segue:

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

Il tag dichiara semplicemente un modello di nome file che deve essere ignorato e un attributo selected che, a sua volta, dichiara il valore di selezione predefinito per il tipo di file nella finestra di dialogo delle preferenze. È compito dell'utente decidere quali file devono essere ignorati. L'utente può selezionare, deselezionare, aggiungere o eliminare i tipi di file dall'elenco predefinito di file ignorati.

Tipi di file

Alcuni repository implementano una gestione differente per i file di testo e i file binari. L'estensione org.eclipse.team.core.fileTypes consente ai plugin di dichiarare i tipi di file come file di testo o come file binari. Ad esempio, la strumentazione Java dichiara quanto segue:

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

Il tag consente ai plugin di definire un tipo di file mediante l'estensione e assegnare un tipo di testo o binario. Come per i file ignorati, spetta in definitiva all'utente gestire l'elenco di tipi di file di testo e binari.

Team e risorse collegate

Un progetto può contenere risorse non ubicate all'interno della directory del progetto nel file system locale. Tali risorse sono denominate risorse collegate.

Conseguenze per i fornitori di repository

Le risorse collegate possono porre alcuni problemi particolari per i fornitori di repository che agiscono direttamente sul file system. Si tratta di una conseguenza del fatto che tali risorse, in base al progetto, non sono presenti nella struttura ad albero di directory del progetto all'interno del file system.

Le risorse collegate possono influire sui fornitori che presentano le seguenti caratteristiche:

  1. Quelli che inviano una chiamata a un programma esterno che agisce direttamente sul file system.
  2. Quelli che vengono implementati in termini di IResource ma presuppongono che tutti i file/cartelle di un progetto siano discendenti diretti della struttura ad albero di directory con origine singola.

Nel primo caso, si supponga che l'utente selezioni una risorsa collegata e tenti di eseguire un'operazione del fornitore su di essa. Dal momento che il fornitore esegue una chiamata a un client della riga comandi, è possibile supporre che effettui un'operazione equivalente alla prima chiamata a IResource.getLocation().toOSString(), inserendo il percorso del file system risultante come argomento del programma della riga comandi. Se la risorsa in questione è una risorsa collegata, restituirà un file/cartella all'esterno della struttura ad albero della directory di progetto. Non tutti client della riga comandi sono in grado di gestire questo caso. In poche parole, se il fornitore ottiene il percorso di una risorsa nel file system, è probabile che richieda operazioni aggiuntive per la gestione delle risorse collegate.

Il secondo caso è abbastanza simile in quanto si basa sul presupposto implicito che la struttura delle risorse del progetto presenti un rapporto di 1:1 con quella dei file/cartelle del file system. In genere, un fornitore può riscontrare problemi se le operazioni IResource e java.io.File vengono mischiate. Ad esempio, per i collegamenti, l'elemento principale di IFile non corrisponde a quello di java.io.File e se il codice presuppone che siano identici verrà generato un errore.

Compatibilità con le versioni precedenti

L'introduzione delle risorse collegate non doveva porre problemi di compatibilità con i fornitori esistenti. In particolar modo, si era preoccupati per i fornitori che presupponevano che la struttura del file system locale riflettesse la struttura del progetto. Di conseguenza, per impostazione predefinita non è possibile aggiungere le risorse collegate ai progetti associati a tali fornitori, né condividere con essi i progetti che contengono risorse collegate.

Strategie per la gestione delle risorse collegate

Per creare collegamenti semplici e stabili, un fornitore deve consentire il controllo delle versioni dei progetti contenenti risorse collegate, con la possibilità di disattivare tale controllo per le risorse collegate stesse.

Una soluzione di gran lunga più complessa consiste nel consentire la creazione di versioni delle risorse collegate effettive. Tale soluzione non è tuttavia consigliata in quanto comporta scenari complessi, ad esempio il file potrebbe già essere sottoposto a un controllo delle versioni in una struttura ad albero di progetto differente da parte di un altro fornitore. Si consiglia pertanto di ricorrere al supporto dei progetti con controllo delle versioni che contengono risorse collegate non sottoposte a tale controllo.

Dettagli tecnici per la creazione di collegamenti semplici

Le implementazioni dei fornitori di repository possono essere aggiornate in modo da supportare le risorse collegate mediante la sostituzione del metodo RepositoryProvider.canHandleLinkedResources() per restituire true. Una volta eseguita questa operazione, le risorse collegate potranno essere presenti nei progetti condivisi con tale fornitore di repository. Tuttavia, il fornitore di repository deve eseguire determinate operazioni allo scopo di verificare che le risorse collegate vengano gestite correttamente. Come accennato, è particolarmente auspicabile che i fornitori di repository ignorino tutte le risorse collegate. Ciò significa che le risorse collegate e i relativi elementi secondari devono essere esclusi dalle operazioni supportate dal fornitore di repository. Inoltre, il fornitore di repository deve utilizzare le funzioni di spostamento ed eliminazione predefinite per le risorse collegate se l'implementazione del fornitore di repository sostituisce l'hook IMoveDeleteHook predefinito.

I fornitori di team possono utilizzare IResource.isLinked() per stabilire se una risorsa rappresenta un collegamento. Questo metodo, tuttavia, restituisce true solo per la directory principale di un collegamento. Il segmento di codice che segue può essere utilizzato per stabilire se una risorsa rappresenta l'elemento secondario di un collegamento.

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

I fornitori di repository devono ignorare le risorse per le quali il codice riportato sopra restituisce true.

Risorse private di team

È molto frequente che le implementazioni di repository utilizzino file e cartelle aggiuntive per memorizzare informazioni specifiche relative all'implementazione. Sebbene questi file possano rivelarsi necessari nello spazio di lavoro, sono del tutto superflui per altri plugin o per l'utente finale.

I fornitori di team possono utilizzare IResource.setTeamPrivateMember(boolean) per indicare che una risorsa è privata nell'implementazione di un fornitore di team. Per impostazione predefinita, le risorse di nuova creazione non sono membri privati. Un uso frequente consiste nel contrassegnare una sottocartella del progetto come risorsa privata di team quando si configura il progetto per il team e si crea la sottocartella.

Un'altra API di risorse che enumera le risorse, ad esempio le strutture ad albero dei delta delle risorse, escluderà i membri privati di team, a meno che non venga esplicitamente richiesto di includerli. Ciò significa che la maggior parte dei client non "vedrà" le risorse private di team e che queste non verranno visualizzate all'utente. Per impostazione predefinita, nella vista Selezione risorse non vengono visualizzati i membri privati di team, ma gli utenti possono indicare tramite le preferenze che desiderano visualizzarli.

I tentativi di contrassegnare i progetti o la directory dello spazio di lavoro come risorse private di team verranno ignorati.

Insiemi di progetti

Poiché le risorse di un progetto sottoposto al controllo delle versioni vengono conservate all'interno del repository, è possibile condividere progetti con membri di team tramite la condivisione di un riferimento alle informazioni specifiche del repository necessarie per ricostruire un progetto nello spazio di lavoro. Tale operazione viene eseguita utilizzando uno speciale tipo di esportazione di file per gli insiemi di progetti di team.  

 

Nella versione 3.0, un'API è stata aggiunta a ProjectSetCapability per consentire ai fornitori di repository di dichiarare una classe che implementi il salvataggio dei progetti sottoposti al proprio controllo. Quando l'utente sceglie di esportare gli insiemi di progetti, vengono visualizzati come candidati per l'esportazione solo i progetti configurati con repository che definiscono insiemi di progetti. Questa API sostituisce la vecchia API di serializzazione dell'insieme di progetti (fare riferimento a quanto riportato in basso).

La classe di funzionalità dell'insieme di progetti per un fornitore di repository viene richiamata dalla classe RepositoryProviderType registrata nella stessa estensione del fornitore di repository. Ad esempio:

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

Prima della versione 3.0, il punto di estensione org.eclipse.team.core.projectSets consentiva ai fornitori di repository di indicare una classe che implementava il salvataggio dei progetti per i progetti sotto il loro controllo. Quando l'utente sceglie di esportare gli insiemi di progetti, vengono visualizzati come candidati per l'esportazione solo i progetti configurati con repository che definiscono insiemi di progetti.

Ad esempio, il client CVS dichiara quanto segue:

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

La classe specificata deve implementare IProjectSetSerializer. L'utilizzo di questa interfaccia è ancora supportato nella versione 3.0 ma risulta obsoleto.