Gestión de recursos del repositorio

Una vez creado un RepositoryProvider, hay otro mecanismo de gestión de recursos que debe comprenderse:

Archivos ignorados

En varios casos, puede que no sea necesario mantener determinados archivos bajo el control del repositorio.  Por ejemplo, los recursos derivados de recursos existentes pueden omitirse frecuentemente del repositorio.  Por ejemplo, los archivos fuente compilados (tales como los archivos ".class" Java) pueden omitirse, ya que el archivo fuente correspondiente (".java") se encuentra en el repositorio.  También puede ser inadecuado el control de versiones de archivos de metadatos generados por proveedores de repositorios.  El punto de extensión org.eclipse.team.core.ignore permite a los proveedores declarar los tipos de archivos que deben pasarse por alto en las operaciones del proveedor de repositorios.  Por ejemplo, el cliente CVS declara lo siguiente:

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

Estos códigos XML tan solo declaran el patrón (pattern) de un nombre de archivo que se debe pasar por alto, y un atributo selected que declara el valor de selección por omisión del tipo de archivo en el diálogo de preferencias.  Es el usuario quien, en última instancia, decide qué archivos deben pasarse por alto.  El usuario puede seleccionar, deseleccionar, añadir o suprimir tipos de archivos en la lista por omisión de archivos ignorados.

Tipos de archivos

Algunos repositorios implementan para los archivos de texto un manejo diferente del de los archivos binarios.  La extensión org.eclipse.team.core.fileTypes permite que los conectores declaren los tipos de archivos como de texto o como binarios.  Por ejemplo, el conjunto de herramientas Java declara lo siguiente:

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

Estos códigos XML permiten que los conectores definan un tipo de archivo por cada elemento extension y asignen un atributo type cuyos valores pueden ser text o binary.  Al igual que con los archivos ignorados, el usuario es quien gestiona, en definitiva, la lista de tipos de archivos de texto y binarios.

Recursos de equipo y enlazados

Un proyecto puede contener recursos que no se encuentren dentro del directorio del proyecto en el sistema de archivos local. Estos recursos se conocen como recursos enlazados.

Consecuencias para los proveedores de repositorios

Los recursos enlazados pueden plantear determinados problemas a los proveedores de repositorios que operan directamente con el sistema de archivos. Esto es consecuencia del hecho de que los recursos enlazados por diseño no existen en el árbol de directorios inmediato del proyecto en el sistema de archivos.

Los proveedores que presenten las siguientes características pueden resultar afectados por los recursos enlazados:

  1. Aquellos que llaman a un programa externo que, a continuación, opera directamente con el sistema de archivos.
  2. Aquellos que se implementan en los términos de IResource, pero presuponen que todos los archivos y carpetas de un proyecto existen como descendientes directos de ese árbol de directorios de raíz única.

En el primer caso, supongamos que el usuario toma un recurso enlazado e intenta realizar en él una operación del proveedor. Dado que el proveedor llama a un cliente de línea de mandatos, podemos suponer que el proveedor realiza alguna acción equivalente a llamar en primer lugar a IResource.getLocation().toOSString(), suministrando la ubicación del sistema de archivos resultante como argumento al programa de línea de mandatos. Si el recurso en cuestión es un recurso enlazado, esta acción producirá un archivo/carpeta situado fuera del árbol de directorios del proyecto. No todos los clientes de línea de mandatos están preparados para esperar y manejar este caso. En pocas palabras, si el proveedor obtiene la ubicación de un recurso en el sistema de archivos, probablemente requerirá un trabajo adicional para manejar los recursos enlazados.

El segundo caso es bastante parecido, en el sentido de que se realiza una suposición implícita de que la estructura de los recursos del proyecto es 1:1 con respecto a los archivos y carpetas del sistema de archivos. En general, un proveedor puede experimentar problemas si mezcla operaciones IResource y java.io.File. Por ejemplo, en el caso de los enlaces, el padre de IFile no es el mismo que el padre de java.io.File, y el código que presupone que son los mismos fallará.

Compatibilidad hacia atrás

Era importante que la introducción de recursos enlazados no implicara la interrupción inadvertida de los proveedores existentes. Específicamente, la preocupación concernía a los proveedores que presuponían razonablemente que la estructura del sistema de archivos local reflejaba la estructura del proyecto. En consecuencia, los recursos enlazados no pueden añadirse por omisión a los proyectos correlacionados con un proveedor de este tipo. Además, los proyectos que contienen recursos enlazados no pueden compartirse por omisión con ese proveedor.

Estrategias de manejo de los recursos enlazados

Para ser "amigo de los enlaces", un proveedor debe permitir que los proyectos con recursos enlazados estén controlados por versión, pero puede impedir el control de versiones de los recursos enlazados en sí.

Una solución considerablemente más compleja consiste en permitir la creación de versiones de los recursos enlazados reales, pero no es aconsejable, ya que presenta escenarios complejos (por ejemplo, el archivo podría estar ya bajo el control de versiones de un árbol de proyectos diferente de otro proveedor). Por tanto, nuestra recomendación es dar soporte a los proyectos con control de versiones que contengan recursos enlazados sin control de versiones.

Detalles técnicos para ser "amigo de los enlaces"

Las implementaciones de proveedor de repositorios pueden actualizarse para dar soporte a los recursos enlazados alterando temporalmente el método RepositoryProvider.canHandleLinkedResources() para que devuelva true. Una vez realizada esta acción, los recursos enlazados podrán existir en proyectos compartidos con ese proveedor de repositorios. Sin embargo, el proveedor de repositorios debe realizar algunas operaciones para asegurarse de que los recursos enlazados se manejan adecuadamente. Como se ha indicado anteriormente, se aconseja encarecidamente que los proveedores de repositorios ignoren todos los recursos enlazados. Esto significa que los recursos enlazados (y sus hijos) deben excluirse de las acciones soportadas por el proveedor de repositorios. Además, el proveedor de repositorios debe utilizar el comportamiento de movimiento y supresión por omisión para los recursos enlazados si la implementación de proveedor de repositorios altera temporalmente el IMoveDeleteHook por omisión.

Los proveedores de equipo pueden utilizar el método IResource.isLinked() para determinar si un recurso es un enlace. Sin embargo, este método sólo devuelve true para la raíz de un enlace. Puede utilizarse el fragmento de código siguiente para determinar si un recurso es hijo de un enlace.

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

Los proveedores de repositorios deben pasar por alto los recursos para los que el código anterior devuelva true.

Recursos privados de equipo

En las implementaciones de los repositorios, es habitual utilizar archivos y carpetas adicionales para almacenar información específica sobre la propia implementación del repositorio.  Estos archivos, si bien pueden ser necesarios en el área de trabajo, no tienen ningún interés para los otros conectores ni para el usuario final.

Los proveedores del equipo pueden usar el método IResource.setTeamPrivateMember(boolean) para indicar que un recurso es privado en la implementación de un proveedor de equipo. Los recursos de nueva creación no son miembros privados por omisión, por lo que hay que usar este método para marcar explícitamente el recurso como privado del equipo.  Un uso habitual consiste en marcar una subcarpeta del proyecto como privada del equipo cuando se configura el proyecto para el equipo y se crea la subcarpeta.

Una API de otros recursos que enumere los recursos (como los árboles de delta de recursos) excluirá los miembros privados del equipo, a menos que se solicite explícitamente que los incluya.  Esto quiere decir que la mayoría de los clientes no "verán" los recursos privados del equipo, y que estos no se mostrarán al usuario.  El navegador de recursos no muestra por omisión los miembros privados del equipo, pero los usuarios, por medio de las preferencias, pueden indicar que desean ver los recursos privados del equipo.

Los intentos de marcar los proyectos o el directorio raíz del área de trabajo como privados del equipo no se tendrán en cuenta.

Conjuntos de proyectos

Dado que los recursos que hay dentro de un proyecto sujeto al control de versiones se conservan en el repositorio, es posible compartir los proyectos con los miembros del equipo compartiendo una referencia a la información específica del repositorio que se necesita para reconstruir un proyecto en el área de trabajo.  Para ello se utiliza un tipo especial de exportación de archivo para los conjuntos de proyectos del equipo.  

 

En la versión 3.0 se ha añadido una API a ProjectSetCapability que permite a los proveedores de repositorios declarar una clase que implementa el guardado de proyectos que se encuentran bajo su control.   Cuando el usuario opta por exportar conjuntos de proyectos, sólo se muestran como candidatos a la exportación los proyectos configurados con los repositorios que definen los conjuntos de proyectos. Esta API sustituye la antigua API de serialización de conjunto de proyectos (consulte la información que figura más adelante).

La clase de posibilidad de conjunto de proyectos de un proveedor de repositorios se obtiene de la clase RepositoryProviderType, que se registra en la misma extensión que el proveedor de repositorios. Por ejemplo:

<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 de la versión 3.0, el punto de extensión org.eclipse.team.core.projectSets permitía a los proveedores de repositorios declarar una clase que implemente el guardado de los proyectos sujetos al control de dichos proveedores.   Cuando el usuario opta por exportar conjuntos de proyectos, sólo se muestran como candidatos a la exportación los proyectos configurados con los repositorios que definen los conjuntos de proyectos.

Por ejemplo, el cliente CVS declara lo siguiente:

<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 clase especificada debe implementar la interfaz IProjectSetSerializer. El uso de esta interfaz sigue estando soportado en la versión 3.0, pero ha quedado obsoleto.