Plastic SCM

Soporte de branching

Para favorecer el desarrollo paralelo, Plastic se centra en dar soporte al branching, que consiste en dividir el desarrollo en distintas ramas, siguiendo una determinada política de uso, protección, desprotección, contenidos, etc. La principal diferencia entre el modelo de branching de Plastic y los implementados por sistemas tales como CVS, Perforce o Team Foundation Server estriba en que en lugar de realizar una copia de todo (o solamente de los metadatos) a cada nueva rama que se genera, las ramas son creadas como objetos vacíos. Solamente cuando un ítem es modificado, la nueva revisión creada es asignada a la rama. Subversion implementa el branching creando copias de toda la rama, pero posponiendo la copia hasta que el fichero es realmente modificado (lo que se conoce como copy-on-write).

De este modo la rama contiene solamente ficheros y directorios que se han modificado o creado con respecto a su rama padre.

Este enfoque permite crear muchas ramas de forma sencilla, haciendo posible la implementación de patrones de branching como por ejemplo el de “rama por tarea”, detallado en el libro SCM Patterns (referencia) y en CM Crossroads (referencia).

El modelo de branching utilizado en Plastic puede compararse con el implementado en Clearcase.

Debido al soporte que la infraestructura del modelo de branching de Plastic aporta, este sistema puede manejar miles de ramas en un solo repositorio sin pérdida notable en el rendimiento.

Ramas inteligentes

Plastic 2.5 (Julio de 2008) introduce el concepto de ramas inteligentes.

Las ramas inteligentes consisten en ramas en las cuales el usuario puede definir una jerarquía de ramas, con soporte de los mecanismos de herencia.

Es importante anotar que una rama en Plastic es simplemente un nuevo objeto en el sistema. Como hemos señalado antes, está vacía desde su creación, pero virtualmente contiene los ficheros y directorios de su progenitor (o progenitores si se utiliza una jerarquía multinivel).

Una rama inteligente puede crearse a partir de una etiqueta específica, un conjunto de cambios (changeset) o una rama particular.

• Herencia de una etiqueta: todo el contenido de la rama procede de la etiqueta, pero si se realizan modificaciones, el cambio va a parar a la rama. Es una buena opción si se desea implementar una corrección de errores (bug fix) en el código a partir de un punto de partida bien conocido y estable.
• Herencia desde un conjunto de cambios: la rama inteligente contiene inicialmente los ficheros y directorios contenidos en el changeset (no los modificados en el changeset, sino el estado de la rama padre en tal changeset).
• Herencia desde una rama: este tipo de herencia es dinámica. La rama toma todas las últimas revisiones de la rama padre, y si algo cambia en la rama padre los cambios son propagados a la rama hija. Las modificaciones en la rama hija son cargadas antes en los progenitores.

La herencia de ramas puede ser configurada en la interfaz gráfica de usuario de Plastic. Pueden establecerse múltiples niveles de herencia a gusto del usuario.

Explorador de ramas

El explorador de ramas es una interfaz de usuario que dibuja todas las ramas de un repositorio. Además representa las relaciones de fusión (merge) entre ramas y las relaciones de herencia.

El explorador de ramas fue introducido por primera vez en Plastic 1.5 y ha sido progresivamente mejorado desde entonces. En la versión 2.0 se introdujo soporte interactivo, de este modo las operaciones comunes entre ramas como por ejemplo la creación, merging o ejecución de consultas comunes pueden ser realizadas desde el propio explorador.

El explorador dibuja:

• Ramas
• Enlaces de merge.
• Enlaces de parentesco entre ramas (herencia).
• Conjuntos de cambios (representados como cuadrados dentro de las ramas).
• Etiquetas.

El explorador permite visualizar los cambios realizados en las ramas o en los conjuntos de cambios.

Árbol de revisiones en 3D

Plastic provee mecanismos para visualizar árboles de revisiones de archivos y directorios. El árbol de revisiones 3D muestra la evolución de un fichero o directorio dado, incluyendo enlaces de las operaciones de merge sufridas (las flechas verdes). Otro tipo de información incluida son las etiquetas y demás datos adicionales.

Más recientemente se han introducido nuevos tipos de información:

• Merges regulares (los representados en verde).
• Merges de intervalo (también conocidos como cherry picks): se representa tanto el intervalo como el merge.
• Merges substractivos.
• Operaciones de inversión.

Directory versioning

Plastic soporta directory versioning. Tanto renombrado como cambios de ubicación de los directorios también están soportados.

Seguimiento de merge

Cada vez que se realiza una operación de merge, se crea un vínculo entre las revisiones origen y destino de la fusión. Tal vínculo es importante no sólo para visualizar el proceso (mostrado en el árbol antes descrito), sino también para que Plastic lo utilice internamente en las siguientes operaciones de merge.

Cuando se funde una rama, se crean vínculos de merge, para que si se vuelve a intentar realizar el merge de nuevo Plastic notifique que no quedan fusiones que realizar.

Herramientas de merge y de diferencias

Plastic incluye las siguientes herramientas:

• Diferencias en el código: permite identificar las diferencias entre dos revisiones de un mismo fichero. Incluye una opción para resaltar la sintaxis.
• Diferencias en imágenes: se soportan dos modos: extremo a extremo o mezclando las dos revisiones a comparar.
• Merge de código: herramienta de merge a tres bandas en el que intervienen la revisión de origen, de destino y la revisión anterior a la modificación.
• Merge binario: permite seleccionar entre revisiones de un fichero binario.
• Diferencias y merge entre directorios: Debido a que PlasticSCM da soporte total a los directorios, existen también interfaces gráficas específicas para ellos.

Seguridad basada en Listas de Control de Acceso (ACL)

Cada objeto ubicado en un repositorio de Plastic tiene una Lista de Control de Acceso (Access Control List, ACL en inglés) asociada. Se incluyen unos 25 tipos de permisos diferentes para permitir o denegar operaciones como por ejemplo protecciones, desprotecciones, fusiones, aplicación de etiquetas, creación de repositorios o espacios de trabajo, etc.

Base de datos de backend configurable

Plastic almacena toda su información y metadatos en bases de datos. Actualmente (versión 2.0), Plastic soporta:

• MySQL (5.0 y siguientes).
• SQL Server (2005 y siguientes).
• Firebird (tanto la configuración embebida como la de servidor. Esta última ofrece un mayor rendimiento).

Plastic utiliza tres tipos de bases de datos diferentes:

• Base de datos de repositorios: almacena información relativa a los repositorios alojados en un servidor determinado.
• Base de datos rep_xxx: una base de datos por repositorio (xxx sería un número en tal caso).
• Base de datos de espacios de trabajo: almacena información relativa a los ficheros y directorios en los cuales trabaja el equipo de desarrollo. En lugar de utilizar directorios ocultos en el espacio de trabajo (workspace) conteniendo información relativa a la copia actual, como hace svn o cvs, Plastic almacena esta información en este servidor.

Las bases de datos pueden consultarse directamente mediante herramientas externas o utilizando el comando de consultas que el propio Plastic ofrece (cm query).

Por defecto Plastic despliega una base de datos Firebird tanto en Windows como en Linux. Esta solución funciona razonablemente bien en entornos pequeños y medianos.

MySQL y SQL Server tienen mejor desempeño en entornos con grandes cargas de trabajo, aportando a Plastic una escalabilidad mayor.

Espacios de trabajo configurables

Un espacio de trabajo es un directorio donde se mapean los contenidos del repositorio. Para seleccionar exactamente qué debe descargarse en el disco del usuario, cada espacio de trabajo tiene un selector asociado. Este selector es bastante similar al config_spec de ClearCase, proporcionando múltiples posibilidades de personalización.