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.

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.

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.

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.

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

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.

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.

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.

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.

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.

Se han lanzado cinco versiones oficiales de Plastic SCM:

• Plastic 1.0: incluye funcionalidad de branching y merging, Firebird como base de datos, seguridad basada en ACL, espacios de trabajo y árbol de revisiones. Incluye, además, integraciones con Eclipse y Visual Studio.
• Plastic 1.5: incluye una versión estándar para equipos de hasta 10 programadores, solamente para Windows y sin soporte de seguridad. La versión profesional incluye las siguientes nuevas funcionalidades:
  • Explorador de ramas: un modo de visualizar las relaciones entre diferentes ramas a nivel de repositorio.
  • Sistema de consultas: comandos como cm query y cm find para ejecutar consultas de metadatos.
  • Soporte de SQL Server como base de datos.
  • Integración con Power Builder, Cruise Control y JDeveloper.
• Plastic 2.0: lanzado el 24 de marzo de 2008. Introduce una interfaz gráfica de usuario rediseñada, además de las siguientes características:
  • La interfaz gráfica de usuario soporta múltiples vistas en la misma pantalla.
  • Interfaz gráfica de usuario soportada en Linux.
  • Desarrollo distribuido: los servidores permiten replicar ramas y reunirlas de nuevo, mediante operaciones de merge.
  • Soporte multiservidor: los servidores de repositorios y espacios de trabajo pueden ser desplegados en distintas máquinas en aras de lograr una mayor escalabilidad.
  • Soporte a la importación desde Subversion, CVS y SourceSafe.
  • Herramienta de ayuda a la revisión de código: una extensión del sistema de consultas que permite inspeccionar cambios realizados en ramas, conjuntos de cambios o etiquetas.
  • Herramienta estadística: muestra gráficamente los cambios, reflejando el progreso del proyecto.
  • Explorador de ramas: mejorado con respecto a la versión anterior. Ahora no sólo es una representación sino que además permite ejecutar acciones.
  • El plug-in de Eclipse introduce la posibilidad de ejecutar la herramienta de diferencias desde el entorno, mostrar etiquetas y ramas, y cambiar entre diferentes ramas.
• Plastic 2.5: Julio de 2008. Añade:
  • Soporte de triggers.
  • Merge substractivo.
  • Un buen número de mejoras en usabilidad de la aplicación.
• Plastic 2.7: Octubre de 2008. Incluye:
  • Sistema distribuido. Permite a los servidores Plastic ser sincronizados.
  • Integración total con Visual Studio.
  • Mejor integración con Eclipse.
  • XMerge.
• Plastic SCM 2.9: Febrero de 2010 incluye las siguientes mejoras
  • Integración con IntelliJ IDEA 5.1 y 8.
  • Integración con Pulse continuous integration server.
  • Soporte de Visual Studio 2010.
  • Workspaces compartidos (Shared Workspaces): los workspaces (espacios de trabajo) ya no están ligados a una máquina concreta sino que pueden ser compartidos en diferentes máquinas al montarlos en unidades de red.
  • Revisión mejorada de ramas: la interfaz de revisión puede utilizarse para recorrer los cambios changeset a changeset permitiendo una mejor comprensión de los cambios, paso a paso.
  • Soporte de links simbólicos (symlinks) en Linux/MacOS X.
  • Soporte de base de datos Oracle como "backend" de datos.
  • Soporte de "sparse trees" y "cloaked items": un usuario puede especificar directorios que no se descargarán durante el update.
  • Múltiples mejoras en los importadores de CVS y VSS (Visual Source Safe).
  • Múltiples mejoras de rendimiento incluyendo soporte para servidores de 64bits.
• Plastic SCM 3.0: Julio de 2010 con las siguientes características:
  • Sistema de revisión de código integrado: la nueva versión incluye la capacidad de realizar revisiones de código de ramas y changesets. El sistema de revisión de código es distribuido.
  • Shell Extension para el explorador de Windows: integración con el explorador de Windows para realizar todas las operaciones disponibles en la interfaz gráfica (tipo TortoiseSVN pero añadiendo todas las capacidades gráficas de Plastic SCM).
  • Nuevos importadores mejorados de Perforce y Subversion.
  • Nueva vista de "cambios pendientes" en la interfaz gráfica, en la "shell extension" y en la integración con Visual Studio. La nueva vista permite tratar de forma homogénea los "check outs", elementos cambiados, privados, etc, haciendo un checkin unificado de todos ellos.
  • Xmerge / Xdiff 2.0: nueva versión de las herramientas de diff y merge que ahora son capaces de detectar código movido.
  • Almacenamiento externo de datos (external data storage): es posible extraer datos de los repositorios a almacenamientos secundarios de modo que revisiones de gran tamaño dejen de ocupar espacio en la base de datos principal. Útil en proyectos con ficheros muy grandes como por ejemplo desarrollo de video-juegos.
  • Soporte de "annotate" en la herramienta gráfica (GUI) y en Visual Studio.
  • Nuevo backend de datos SQLite: se incluye por defecto para las evaluaciones en Linux y en MacOS X. Es efectivo para entornos con pocos usuarios y evaluaciones. Útil también en servidores replicados.
  • Explorador de selectors: es posible explorar el repositorio por ramas, etiquetas y changesets.
  • Mejoras de rendimiento y escalabilidad.

• Control de versiones
• Programas para control de versiones

• Web oficial de Plastic SCM
• Códice Software Empresa desarrolladora de Plastic SCM

1. Berczuk, Steve; Brad Appleton (2003). Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley. ISBN 0-201-74117-2. [1]. Retrieved on 2007-05-24.
2. "Streamed Lines: Branching Patterns for Parallel Software Development". CM Crossroads. [2]. Retrieved on 2007-05-24.