Uma vez criado o RepositoryProvider,
há outro mecanismo de gestão de recursos que importa compreender:
Em vários casos, poderá ser desnecessário manter certos ficheiros sob o controlo do repositório. Por exemplo, recursos que sejam derivados de recursos existentes podem ser omitidos do repositório. Por exemplo, ficheiros origem compilados (como, por exemplo, ficheiros ".class" Java) podem ser omitidos dado que o ficheiro origem correspondente (".java") está no repositório. Poderá também não ser apropriado versionar ficheiros de metadados de controlo que sejam gerados por fornecedores de repositórios. O ponto de extensão org.eclipse.team.core.ignore permite aos fornecedores declararem tipos de ficheiros que devam ser ignorados para operações de fornecedores de repositórios. Por exemplo, o cliente CVS declara o seguinte:
<extension point="org.eclipse.team.core.ignore">
<ignore pattern = ".#*" selected = "true"/>
</extension>
A marcação declara simplesmente um padrão de nome de ficheiro que deva ser ignorado e um atributo seleccionado que declare o valor de selecção predefinido do tipo de ficheiro no diálogo de preferências. Compete ao utilizador decidir quais os ficheiros a ignorar. O utilizador poderá seleccionar, desmarcar, adicionar ou eliminar tipos de ficheiros da lista predefinida de ficheiros ignorados.
Alguns repositórios implementam tratamento especial para ficheiros de texto versus binários. O ponto de extensão org.eclipse.team.core.fileTypes permite aos plug-ins declararem tipos de ficheiros como texto ou binários. Por exemplo, as ferramentas Java declaram o seguinte:
<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 marcação deixa os plug-ins definirem um tipo de ficheiro por extensão e atribuir umtipo texto ou binário. Tal como com os ficheiros ignorados, compete ao utilizador gerir a lista de tipos de ficheiro de texto e binários.
Um projecto poderá conter recursos que não se encontrem no directório do projecto no sistema de ficheiros local. Estes recursos chamam-se recursos ligados .
Os recursos ligados podem constituir verdadeiros desafios para fornecedores de repositórios que funcionem directamente no sistema de ficheiros. Trata-se de uma consequência do facto de os recursos ligados por concepção não existirem na árvore de directórios do projecto imediato no sistema de ficheiros.
Os fornecedores que mostrem as seguintes características poderão ser afectados por recursos ligados:
No primeiro caso, suponhamos que o utilizador pega num recurso ligado e tenta executar uma operação de fornecedor nele. Dado que o fornecedor chama um cliente de linha de comandos, podemos supor que o fornecedor realiza algo equivalente a chamar primeiro IResource.getLocation().toOSString(), inserindo a localização do sistema de ficheiros resultante como argumento para o programa de linha de comandos. Se o recurso em questão for um recurso ligado, irá resultar num ficheiro/pasta fora da árvore de directórios do projecto. Não se pode esperar que todos os clientes de linha de comandos podem tratar deste caso. Em suma, se o fornecedor obtiver a localização no sistema de ficheiros de um recurso, irá precisar de mais trabalho para tratar recursos ligados.
O segundo caso é muito semelhante no sentido em que se supõe implicitamente que a estrutura dos recursos do projecto é 1:1 com a dos ficheiros/pastas do sistema de ficheiros. Regra geral, um fornecedor poderá ter problemas se misturar operações IResource e java.io.File. Por exemplo, no caso de ligações, o ascendente de IFile não é o mesmo que o ascendente de java.io.File, pelo que o código que parta desta suposição irá falhar.
Era importante que a introdução de recursos ligados não danificasse inadvertidamente os fornecedores existentes. Mais especificamente, a preocupação incidia em fornecedores que supusessem razoavelmente que a estrutura do sistema de ficheiros local reflectia a estrutura do projecto. Por conseguinte, e por predefinição, os recursos ligados não podem ser adicionados a projectos que estejam correlacionados com tal fornecedor. Além disso, os projectos que contenham recursos ligados não podem, por predefinição, ser partilhados com esse fornecedor.
Para poder ser compatível com ligações, um fornecedor deve permitir que projectos com recursos ligados tenham as respectivas versões controladas, mas poder desautorizar o controlo de versões dos recursos ligados propriamente ditos.
Um solução muito mais complexa seria permitir o versionamento dos recursos ligados propriamente ditos, mas isto deve ser desencorajado dado que acarreta cenários complexos (p.ex., o ficheiro poderá já ter controlo de versões numa árvore de projectos diferente e por outro fornecedor). Por conseguinte, a nossa recomendação incide em suportar projectos sob controlo de versões que contenham recursos ligados livres de controlo de versões.
As implementações de fornecedores de repositórios podem ser actualizadas para suportar recursos ligados mediante sobreposição do método RepositoryProvider.canHandleLinkedResources() para devolver true. Uma vez feito isto, os recursos ligados poderão existir em projectos partilhados com esse fornecedor de repositórios. Todavia, o fornecedor de repositórios deve tomar medidas para garantir o tratamento correcto dos recursos ligados. Tal como mencionámos em cima, sugerimos fortemente que os fornecedores de repositórios ignorem todos os recursos ligados. Significa isto que os recursos ligados (e seus descendentes) devem ser excluídos das acções suportadas pelo fornecedor de repositórios. Mais, o fornecedor de repositórios deve utilizar o comportamento predefinido de mover e eliminar para recursos ligados, se a implementação do fornecedor de repositórios se sobrepuser ao IMoveDeleteHook predefinido.
Os fornecedores de equipa podem utilizar um IResource.isLinked() para determinar se um recurso é ou não uma ligação. No entanto, este método só devolve verdadeiro (true) relativamente à raiz de uma ligação. Pode utilizar-se o segmento de código seguinte para determinar se um recurso é descendente de uma ligação.
String linkedParentName = resource.getProjectRelativePath().segment(0);
IFolder linkedParent = resource.getProject().getFolder(linkedParentName);
boolean isLinked = linkedParent.isLinked();
Os fornecedores de repositórios devem ignorar recursos relativamente aos quais o código supra devolver true.
É comum nas implementações de repositórios utilizar ficheiros e pastas adicionais para armazenar informações específicas sobre a implementação do repositório. Embora estes ficheiros possam ser necessários no espaço de trabalho, não têm interesse para outros plug-ins nem para o utilizador final.
Os fornecedores de equipa poderão utilizar IResource.setTeamPrivateMember(boolean) para indicar que um recurso é privado para a implementação de um fornecedor de equipa. Os recursos recentemente criados não são membros privados por predefinição, de modo que este método deve ser usado para marcar explicitamente o recurso como privado de equipa. Uma utilização comum consiste em marcar uma subpasta do projecto como privada de equipa quando o projecto é configurado para equipa e a subpasta é criada.
As outras APIs de recursos que enumeram recursos (como, por exemplo, árvores delta de recursos) irão excluir membros privados de equipa, salvo quando explicitamente solicitado para os incluir. Significa isto que a maioria dos clientes não "vê" os recursos privados de equipa e estes não são mostrados ao utilizador. Por predefinição, o navegador de recursos não mostra membros privados de equipa, mas os utilizadores podem indicar nas Preferências que gostariam de ver membros privados de equipa.
As tentativas de marcar projectos ou a raiz do espaço de trabalho como privados de equipa serão ignoradas.
Dado que os recursos dentro de um projecto sob controlo de versões são mantidos no repositório, é possível partilhar projectos com membros da equipa, partilhando uma referência às informações específicas de repositórios necessárias à reconstrução de um projecto no espaço de trabalho. Tal realiza-se com um tipo especial de exportação de ficheiros para conjuntos de projectos de equipa.
Na versão 3.0, foi adicionada uma API ao ProjectSetCapability para permitir aos fornecedores de repositórios declararem uma classe que implemente salvaguarda de projectos sob o seu controlo. Quando o utilizador optar por exportar conjuntos de projectos, só são mostrados os projectos configurados com repositórios que definam conjuntos de projectos como candidatos à exportação. Esta API substitui a antiga API de serialização de conjuntos de projectos (ver infra).
A classe de capacidade de conjuntos de projectos para um fornecedor de repositórios obtém-se junto da classe RepositoryProviderType, a qual está registada na mesma extensão que o fornecedor de repositórios. Por exemplo:
<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>
Antes da verão 3.0, o ponto de extensãoorg.eclipse.team.core.projectSets permitia aos fornecedores de repositórios declararem uma classe que implementava salvaguarda de projectos sob o seu controlo. Quando o utilizador optar por exportar conjuntos de projectos, só são mostrados os projectos configurados com repositórios que definam conjuntos de projectos como candidatos à exportação.
Por exemplo, o cliente CVS declara o seguinte:
<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 classe especificada deve implementar IProjectSetSerializer. Esta interface ainda é suportada na versão 3.0 mas está obsoleta.