-1-

Manual de Usuario
 Manual de Usuario

Contenido
1. Introducción ..................................................................................... 3
1.1. ¿Qué es Plastic SCM?..................................................................... 3
1.2. Problemas sin un sistema de control de versiones.............................. 3
1.3. Componentes ............................................................................... 4
2. Conceptos básicos de Plastic SCM..................................................... 6
2.1. Repositorio .................................................................................. 6
2.2. Ítem o elemento ........................................................................... 7
2.3. Revisiones ................................................................................... 8
2.4. Rama (branch) ............................................................................. 9
El árbol de versiones ........................................................................ 12
El explorador de ramas ..................................................................... 13
2.5. Ramas inteligentes (smart) .......................................................... 14
2.6. Workspace (espacio de trabajo) .................................................... 15
2.7. Etiqueta (Label).......................................................................... 16
3. Operaciones de Plastic SCM ............................................................ 18
3.1. Creando un repositorio ................................................................ 19
3.2. Crear espacios de trabajo............................................................ 19
3.3. Add (Añadir) .............................................................................. 20
3.4. Check in (proteger) ..................................................................... 25
3.5. Update (obtener) ........................................................................ 27
Ítems modificados en el espacio de trabajo.......................................... 27
Ítems marcados como .unloaded........................................................ 28
Resguardo automático de desprotecciones (Checkout shelving) .............. 28
Update paralelo ............................................................................... 30
3.6. Check out (desproteger) .............................................................. 30
Detalles internos de la operación de check out ..................................... 32
3.7. Viendo las protecciones pendientes ............................................... 33
3.8. Uncheckout (cancelar una desprotección) ....................................... 34
3.9. Crear una rama .......................................................................... 35
3.10. Merge (integración)..................................................................... 35
Tipos de conflicto de merge ............................................................... 36
Contribuidores................................................................................. 37
Merges desde la misma rama ............................................................ 38
Merges desde ramas diferentes.......................................................... 39
Merge desde una rama y una etiqueta ................................................ 40
Merge desde una etiqueta ................................................................. 41
Merge desde un changeset ................................................................ 42
Merge desde una revisión.................................................................. 42
Cherry Picking ................................................................................. 43
Cherry Picking desde rama ................................................................ 45
Merge de un intervalo de cambios ...................................................... 46
3.11. Crear una etiqueta ...................................................................... 46
3.12. Aplicar una etiqueta .................................................................... 47
3.13. Poner código existente bajo el control de versiones.......................... 48
4. Empezando un proyecto.................................................................. 50
4.1. Creando un repositorio ................................................................ 50
4.2. Creación de un espacio de trabajo ................................................. 51
4.3. Poner código existente bajo el control de versiones.......................... 52
4.4. Empezando a trabajar: Obtener .................................................... 55
4.5. Desprotegiendo ítems para trabajar con ellos.................................. 56
4.6. Mostrando las protecciones pendientes .......................................... 57
5. Selectores en profundidad .............................................................. 59
5.1. Aspecto de un selector................................................................. 59
 Manual de Usuario

5.2. Definición del selector.................................................................. 60

5.3. Reglas de path ........................................................................... 61
5.4. La opción norecursive de la regla path ........................................... 62
5.5. Comodines en la regla de selección de path .................................... 63
5.6. Obteniendo una revisión específica de un ítem ................................ 64
6. Especificaciones de objetos ............................................................ 65
6.1. Especificaciones de revisión.......................................................... 65
6.2. Especificaciones de rama ............................................................. 66
6.3. Especificaciones de ítem .............................................................. 66
6.4. Especificaciones de etiqueta ......................................................... 66
6.5. Especificaciones de repositorio ...................................................... 66
6.6. Especificaciones de espacio de trabajo ........................................... 67
6.7. Especificaciones de servidor de repositorios .................................... 67
6.8. Especificaciones de servidor de workspaces .................................... 67
7. Interfaz gráfica............................................................................... 68
7.1. Ventana principal ........................................................................ 68
7.2. Sistema de vistas........................................................................ 70
7.3. Selección del espacio de trabajo.................................................... 70
7.4. Modificar el selector .................................................................... 70
7.5. Menús contextuales..................................................................... 71
7.6. Diálogo de diferencias ................................................................. 75
7.7. Herramienta de diferencias de código ............................................ 76
7.8. Herramienta de diferencias de imágenes ........................................ 77
7.9. El diálogo de merge .................................................................... 78
7.10. Herramienta de merge para ficheros de texto ................................. 79
7.11. La herramienta de merge binario .................................................. 81
8. Gestionando proyectos con Plastic SCM .......................................... 83
8.1. Trabajando en la rama principal .................................................... 83
8.2. Rama por desarrollador ............................................................... 84
8.3. Rama por tarea .......................................................................... 85
9. Visual Studio Plug In ...................................................................... 87
9.1. Añadir proyectos al control de código fuente ................................... 87
9.2. Abrir proyectos existentes en el control de código fuente .................. 88
9.3. Operaciones básicas .................................................................... 89
9.4. Otras operaciones de control de código fuente ................................ 90
9.5. Trabajar desconectado................................................................. 91
10. Eclipse Plug In ................................................................................ 92
10.1. Añadir proyectos al control de código fuente ................................... 92
10.2. Abrir proyectos existentes en el control de código fuente .................. 95
10.3. Operaciones básicas .................................................................... 95
10.4. Soporte de refactor ..................................................................... 97
10.5. Preferencias ............................................................................... 98
10.6. Decoradores............................................................................... 99
10.7. La Perspectiva Plastic SCM ........................................................... 99
10.7.1. Vista de consola...................................................................100
10.7.2. Vista de Explorador de espacios de trabajo ..............................100
10.7.3. Vista de Desprotecciones pendientes.......................................102
11. Integración con JDeveloper .......................................................... 103
11.1. Añadir proyectos al control de código fuente ..................................103
11.2. Operaciones ..............................................................................105
11.3. Decoradores..............................................................................107
12. IntelliJ 5 Plug in ........................................................................... 108
12.1. Configurar el Plug in ...................................................................108
12.2. Checkout from Version Control.....................................................110
 Manual de Usuario

12.3. Breve reseña sobre el estado de los ítems. ....................................114

12.4. Abrir proyectos existentes en el control de código fuente .................114
12.5. Operaciones básicas ...................................................................114
12.6. Soporte de refactor ....................................................................121
13. IntelliJ 8 Plug in ........................................................................... 122
13.1. Configurar el Plug in ...................................................................122
13.2. Checkout from Version Control.....................................................124
13.3. Breve reseña sobre el estado de los ítems. ....................................127
13.4. Abrir proyectos existentes en el control de código fuente .................127
13.5. Operaciones básicas ...................................................................127
13.6. Soporte de refactor ....................................................................135
13.7. Trabajo fuera de línea (Work offline).............................................135
14. Sistema de consultas .................................................................... 136
14.1. Lenguaje de consulta..................................................................136
14.2. Ejemplos de uso ........................................................................140
14.3. La gramática del lenguaje de consultas .........................................142
15. Sistema de consultas avanzado (AQS).......................................... 143
15.1. Lenguaje de consulta..................................................................144
15.2. Ejemplos de uso ........................................................................148
16. Importar desde otros SCM ............................................................ 150
16.1. Introducción..............................................................................150
16.2. Modo de funcionamiento .............................................................150
16.2.1. Pasos previos ......................................................................150
16.2.2. Ejecución ............................................................................151
16.2.3. Usuarios .............................................................................151
16.2.4. Mecanismo de importación ....................................................152
16.3. Proveedores de importación ........................................................153
16.3.1. Microsoft Visual SourceSafe ...................................................153
16.3.2. CVS ...................................................................................154
16.3.3. Subversion..........................................................................154
17. Referencias................................................................................... 156
 Manual de Usuario

Tablas
Tabla 1: El menú de ítem........................................................................ 72
Tabla 2: Menú de rama ........................................................................... 73
Tabla 3: Menú de etiqueta ....................................................................... 73
Tabla 4: Menú de elementos privados........................................................ 74
Tabla 5: Menú de revisiones..................................................................... 75
Tabla 6. Opciones de merge ..................................................................... 79
 Manual de Usuario

Figuras
Figura 1. Componentes y estructura de Plastic SCM....................................... 5 
Figura 2. Objetos almacenados en un repositorio .......................................... 6 
Figura 3: Ejemplo de ítems bajo control de versiones y elementos privados ...... 7 
Figura 4. Ítems y revisiones ....................................................................... 8 
Figura 5: Ejemplo de historial de un ítem ..................................................... 8 
Figura 6: Evolución (historia) de un ítem ..................................................... 9 
Figura 7: Revisiones de un ítem contenidas en una rama ............................... 9 
Figura 8: Representación de una rama ...................................................... 10 
Figura 9: Representación de la herencia de ramas....................................... 10 
Figura 10: Cómo el espacio de trabajo carga unas revisiones en particular...... 11 
Figura 11: El árbol de versiones en la estructura del repositorio .................... 12 
Figura 12: El árbol de versiones del ítem hello.cpp calculado por Plastic SCM .. 12 
Figura 13: Ejemplo de árbol de versiones de un elemento ............................ 13 
Figura 14: Ejemplo del explorador de ramas............................................... 13 
Figura 15: Ramas definiendo la jerarquía dinámica de ramas ........................ 15 
Figura 16. Cómo se mapean revisiones a workspaces .................................. 16 
Figura 17. Cada desarrollador puede tener varios workspaces ....................... 16 
Figura 18. Etiquetas aplicadas a revisiones................................................. 17 
Figura 19. Operaciones básicas de control de versiones................................ 18 
Figura 20: Diálogo de creación de repositorio ............................................. 19 
Figura 21: Creando un espacio de trabajo .................................................. 20 
Figura 22: Elementos recién añadidos desde Visual Studio............................ 22 
Figura 23: Agregar solución al control de código fuente................................ 23 
Figura 24: Elementos protegidos............................................................... 24 
Figura 25: Agregar a control de versiones en Eclipse ................................... 24 
Figura 26: Añadir a Plastic recursivamente ................................................. 25 
Figura 27: Proteger recursivamente desde Eclipse ....................................... 25 
Figura 28: Lista de protecciones pendientes antes de proteger los ítems......... 27 
Figura 29: Ficheros desprotegidos antes del update..................................... 29 
Figura 30: Protección de ficheros en check out............................................ 29 
Figura 31: Ficheros desprotegidos en la rama ............................................. 29 
Figura 32: Recuperación de contenidos del check out................................... 30 
Figura 33: Detalle de elemento desprotegido en Visual Studio....................... 31 
Figura 34: Diálogo de desprotección de Visual Studio 2003........................... 32 
Figura 35. Creación de una revisión durante la operación de check out........... 32 
Figura 36. Listar las revisiones desprotegidas ............................................. 33 
Figura 37: Opción "Mostrar protecciones pendientes" en Visual Studio............ 33 
Figura 38: Cancelar una desprotección desde la línea de comandos ............... 34 
Figura 39: Creando una rama hija desde la interfaz gráfica........................... 35 
Figura 40: Ejemplo de ítems que necesitan merge....................................... 36 
Figura 41: Revisiones implicadas en una operación de merge........................ 37 
Figura 42. Situación que necesitará un merge desde la misma rama .............. 38 
Figura 43. Ejemplo básico de merge, merge terminado ................................ 39 
Figura 44: Escenario de desarrollo paralelo ................................................ 39 
Figura 45. Los desarrolladores evolucionan las revisiones ............................. 40 
Figura 46: Las dos ramas han sido integradas ............................................ 40 
Figura 47: La revisiones etiquetadas en la rama han sido integradas.............. 41 
Figura 48: Operación de merge ................................................................ 45 
Figura 49: Cherry-pick ............................................................................ 45 
Figura 50: Creación de una nueva etiqueta ................................................ 47 
Figura 51: Aplicar etiqueta al contenido del espacio de tabajo ....................... 48 
Figura 52: Diálogo de creación de repositorio ............................................. 51 
Figura 53: Creando un espacio de trabajo .................................................. 52 
Figura 54: Agregar la solución al control de código fuente ............................ 53 
Figura 55: Ítems en estado protegido ........................................................ 53 
 Manual de Usuario

Figura 56: Añadir el proyecto a Plastic SCM ................................................ 54 

Figura 57: Elementos desprotegidos en Plastic SCM..................................... 54 
Figura 58: Protección recursiva................................................................. 55 
Figura 59. Realizando una operación de Obtener ......................................... 55 
Figura 60: Detalle de elemento desprotegido en Visual Studio....................... 56 
Figura 61: Diálogo de desprotección de Visual Studio 2003........................... 57 
Figura 62. Listar las revisiones desprotegidas ............................................. 57 
Figura 63. Apariencia del selector por defecto ............................................. 59 
Figura 64. Definición de la gramática del selector ........................................ 61 
Figura 65. Estructura de repositorio de ejemplo .......................................... 63 
Figura 66: Selección de un espacio de trabajo ............................................ 68 
Figura 67. Ventana principal de GUI .......................................................... 69 
Figura 68: Selección del espacio de trabajo ................................................ 70 
Figura 69: Diálogo de edición del selector .................................................. 71 
Figura 70: Diálogo de diferencias .............................................................. 75 
Figura 71: Diferencias de directorios mostrando un fichero añadido ............... 76 
Figura 72: Diferencia de código con sintaxis resaltada ................................. 77 
Figura 73: Diferencia de imágenes mostrando gráficos en paralelo ................ 77 
Figura 74: Herramienta de diferencias gráficas mostrando imágenes combinadas
........................................................................................................... 78 
Figura 75: El diálogo de merge ................................................................. 78 
Figura 76: Diálogo de selección de ficheros de merge tool ............................ 80 
Figura 77: Herramienta de merge para ficheros de texto .............................. 80 
Figura 78: La herramienta de merge ......................................................... 81 
Figura 79: Herramienta de merges binarios ................................................ 82 
Figura 80: Todos los cambios en la rama principal....................................... 83 
Figura 81: Patrón de rama por desarrollador .............................................. 84 
Figura 82: El patrón de rama por tarea ...................................................... 85 
Figura 83: Añadir al control de versiones desde Visual Studio ....................... 88 
Figura 84: Cambiar de control de código fuente en Visual Studio ................... 88 
Figura 85: Enlazar proyectos .................................................................... 89 
Figura 86: Operaciones sobre un fichero protegido ...................................... 89 
Figura 87: Operaciones sobre un fichero desprotegido ................................. 89 
Figura 88: Operaciones SCM adicionales en Visual Studio ............................. 90 
Figura 89: Cambiar control de código fuente .............................................. 91 
Figura 90: Desprotección sin conexión ....................................................... 91 
Figura 91: Protección tras recuperar la conexión ......................................... 91 
Figura 92: Opción para compartir el proyecto ............................................. 93 
Figura 93: Selección del control de versiones que se va a utilizar: Plastic SCM. 93 
Figura 94: Ruta del ejecutable para la instalación de Plastic SCM................... 94 
Figura 95: Opción para añadir el proyecto a Plastic SCM............................... 94 
Figura 96: Elementos desprotegidos en Eclipse ........................................... 94 
Figura 97: Protección de los elementos del proyecto .................................... 95 
Figura 98: Operaciones del Plugin de Eclipse .............................................. 96 
Figura 99: Barra de herramientas de Plastic SCM en Eclipse.......................... 97 
Figura 100: Cuadro de preferencias........................................................... 98 
Figura 101: Decoradores de Plastic SCM en Eclipse...................................... 99 
Figura 102: Selección de Plastic SCM como control de versiones...................104 
Figura 103: Localización de Plastic SCM ....................................................104 
Figura 104: Preferencia vacía ..................................................................105 
Figura 105: Actualizar el estado...............................................................105 
Figura 106: Operaciones de Plastic SCM desde JDeveloper ..........................106 
Figura 107: Error al hacer cambios sin desproteger ....................................106 
Figura 108: Ventana de Settings de IntelliJ5.1 ...........................................109 
Figura 109: Diálogo de configuración de control de versiones de IntelliJ5.1 ....109 
Figura 110: Configuración del plugin de PlasticSCM para IntelliJ5.1...............110 
Figura 111: Resultado satisfactorio de un Test Connection...........................110 
 Manual de Usuario

Figura 112: Pantalla principal de IntelliJ5.1, destacando la opción de Check out

from Version Control ..............................................................................111 
Figura 113: Selección de repositorio, rama y etiqueta. ................................112 
Figura 114: Selección de workspace. ........................................................113 
Figura 115: Diálogo de creación de un nuevo workspace. ............................113 
Figura 116: Muestra del código de colores utilizado para resaltar el estado de los
ítems. ..................................................................................................114 
Figura 117: Operaciones de PlasticSCM aplicables a un ítem. .......................115 
Figura 118: Diálogo de checkin................................................................116 
Figura 119: Diálogo de checkin para directorios. ........................................117 
Figura 120: Diálogo de IDEA para quitar la propiedad de sólo lectura de un ítem.
..........................................................................................................118 
Figura 121: Vista de historial de un ítem...................................................118 
Figura 122: Comando Annotate para un fichero controlado por PlasticSCM.....119 
Figura 123: Menú Version Control de IntelliJ5.1, con las opciones de PlasticSCM.
..........................................................................................................119 
Figura 124: Diálogo de actualización de proyecto .......................................120 
Figura 125: Diálogo de merge. ................................................................121 
Figura 126: Ventana de configuración de IntelliJ 8......................................122 
Figura 127: Detalle de la asociación del proyecto a Plastic SCM. ...................123 
Figura 128: Configuración del plugin de Plastic SCM para IntelliJ 8 ...............123 
Figura 129: Resultado satisfactorio de un Test Connection...........................124 
Figura 130: Pantalla principal de IntelliJ 8, destacando la opción de Check out
from Version Control ..............................................................................124 
Figura 131: Selección de repositorio y rama o etiqueta. ..............................125 
Figura 132: Selección de workspace como destino de la operación................125 
Figura 133: Diálogo de creación de un nuevo workspace. ............................126 
Figura 134: Resumen de la operación de Check Out from Version Control que se
va a realizar. ........................................................................................126 
Figura 135: Muestra del código de colores utilizado para resaltar el estado de los
ítems. ..................................................................................................127 
Figura 136: Operaciones de Plastic SCM aplicables a un ítem. ......................128 
Figura 137: Diálogo de checkin................................................................129 
Figura 138: Diálogo de IntelliJ para quitar la propiedad de sólo lectura de un
ítem. ...................................................................................................130 
Figura 139: Vista de historial de un ítem...................................................130 
Figura 140: Comando Annotate para un fichero controlado por Plastic SCM....131 
Figura 141: Menú Version Control de IntelliJ 8, con las opciones de Plastic SCM.
..........................................................................................................132 
Figura 142: Diálogo de actualización de proyecto .......................................133 
Figura 143: Diálogo de creación de una rama nueva...................................133 
Figura 144: Diálogo de merge. ................................................................134 
Figura 145: Diálogo de creación de workspace...........................................134 
Figura 146: Opción de trabajar fuera de línea. ...........................................135 
 Manual de Usuario

Prólogo
Una breve introducción a la gestión de configuración de software
Una solución de gestión de configuración de software suele contener los
siguientes componentes:
• Identificación de la configuración, por lo que se puede saber en qué
módulo de código fuente se está trabajando
• Control de configuración, que implica controlar el ciclo de entrega
(release) de un producto y sus cambios a lo largo de su ciclo de vida, de
modo que se pueden crear líneas base consistentes del producto
• Auditoría de estados: se pueden registrar y crear informes sobre el
estado de los componentes y las peticiones de cambio para ayudar a
medir algunos aspectos sobre la calidad y el proceso de cambio
• Revisiones, para validar el grado de finalización de un producto y ayudar
a mantener la consistencia entre los componentes
• Gestión de compilaciones (build management), que facilita la creación y
mantenimiento de un proceso de construcción repetible
• Gestión de procesos, asegura que aquellos que producen y entregan el
software siguen los procesos de desarrollo de la organización.
Sin embargo, el tener todas estas piezas no significa que la solución SCM
(Software Configuration Management) vaya a ser efectiva. Para tener una
solución efectiva (al contrario que completa) es necesario entender que hay más
de una manera de implementar todos los elementos de la lista anterior y que el
modo de hacerlo variará de una organización a otra. Es también imprescindible
ver que los elementos enumerados se enfocan a muy alto nivel y que para que el
proceso funcione día a día es necesario centrarse también en micro actividades:
todo lo que ocurre en el espacio de trabajo del desarrollador debe ser correcto.
Hay que recordar que la razón de tener procesos y herramientas SCM es la
comunicación y poder favorecer el trabajo en equipo.
Un proceso SCM efectivo ha de estar integrado completamente con la
arquitectura, con la organización estructural de la empresa y por supuesto, con
su cultura. Un proceso SCM adecuado para una empresa de nueva creación de 3
personas creando un nuevo sistema web no tiene por qué ser válido para un
gran proyecto con gente trabajando desde varios países. Lo que ambas
organizaciones deben compartir es que su proceso sea fácil de usar y que
permita repetitividad. Es aquí donde el buen uso de patrones entra en juego.
Uno de los elementos claves que el proceso SCM debería permitir, pero que
normalmente no suele tenerse en consideración, es la posibilidad de que los
desarrolladores puedan crear espacios de trabajo privados que contengan la
versión de la aplicación con la que tienen que trabajar. También la capacidad de
que los desarrolladores puedan compilarla completamente antes de integrar sus
cambios y de realizar pruebas para verificar que todos los cambios cumplen con
las expectativas.
La razón fundamental de tener un proceso SCM efectivo es facilitar la
comunicación. Un buen SCM permitirá que todos los miembros del equipo
trabajen juntos.
Stephen P. Berczuk - Octubre 2006
 Manual de Usuario

Acerca de este manual

Este manual describe el uso normal del producto Plastic SCM desarrollado por
Códice Software. En él se presentarán características y técnicas para obtener el
máximo rendimiento de la herramienta.
A quién está dirigido
Esta guía está dirigida al desarrollador medio, asumiendo que el lector está
familiarizado con conceptos básicos del sistema operativo, algún lenguaje de
programación y entornos de desarrollo como Microsoft Visual Studio o Eclipse.
Documentación online
Además de este manual y el resto de guías, Plastic SCM proporciona una
referencia online a través de su página web y su blog.
Desde la línea de comandos (tanto Windows como Linux) es posible teclear:

cm help

Para obtener información acerca de todos los comandos disponibles, y

cm help command

Para obtener información acerca de un comando específico.

Desde las herramientas gráficas es posible acceder a la ayuda Online en el menú
de ayuda.
Errores en la documentación
Si encuentra algún problema en cualquiera de las guías, o en alguna parte de la
ayuda online, por favor, notifíquelo a la siguiente dirección de correo electrónico:

[email protected]

2
 Manual de Usuario

1. Introducción

1.1. ¿Qué es Plastic SCM?

Plastic SCM es un completo sistema de Gestión de Configuración del Software
(SCM) capaz de gestionar la evolución y cambios del código fuente en el tiempo.
Mejora la visibilidad y la gestión en el desarrollo paralelo, asegurando una
colaboración óptima de los equipos, y añadiendo novedosas fórmulas de
visualización en una interfaz amigable.

1.2. Problemas sin un sistema de control de versiones

Los grupos de desarrollo que no usan control de versiones están muy
posiblemente familiarizados con los siguientes problemas:
• La versión actual del código se sobrescribe accidentalmente con otra más
antigua.
• Un cambio crítico se descarta erróneamente de una entrega a un cliente.
• Se hacen cambios a una versión incorrecta del sistema.
• Bugs arreglados reaparecen de nuevo.
• Es difícil (o imposible) determinar qué versiones de cada fichero están en
una entrega concreta. Este problema puede tener diferentes niveles de
gravedad: desde no saber exactamente la versión de ciertos elementos
hasta un total agujero negro en el que no hay manera fácil de conocer a
qué fuentes se corresponden los binarios en producción.
• Las compilaciones no son reproducibles. No hay una manera fácil de
reconstruir una entrega antigua, porque los fuentes y sus dependencias
(librerías, componentes) no están correctamente gestionados.

3
 Manual de Usuario

• Enorme sobrecarga cuando se mantienen diferentes releases en

producción. Es un escenario muy común para una empresa, ya sea una
organización centrada en proyectos o en producto, tener más de una
versión de su software en producción. Sin la ayuda de un SCM adecuado,
gestionar correcciones, cambios y mejoras es una auténtica pesadilla.
• No hay una forma sencilla de comprobar los cambios hechos al código o a
recursos asociados (imágenes, ayudas, manuales).
• Los jefes de proyecto tienen problemas graves para medir el avance.
• Pobre comunicación entre los miembros del equipo.
Prácticamente todos los problemas descritos pueden resolverse haciendo buen
uso de herramientas SCM. Este manual mostrará cómo Plastic SCM puede ser la
clave para afrontar toda esa problemática.

1.3. Componentes
Plastic SCM está diseñado en torno a una arquitectura de cliente y servidor.
• El servidor es responsable de almacenar toda la información de los
proyectos, y arbitra el acceso de los clientes a dicho almacén.
• Los clientes son ejecutados por cada desarrollador en su equipo, y son
responsables de comunicar al servidor las operaciones que hacen los
desarrolladores. Los clientes básicos y sus plataformas soportadas son los
siguientes:
o Cliente de línea de comandos (CLI): da acceso a todas las
operaciones a través de comandos desde el Shell del sistema.
o Cliente gráfico: da acceso a todas las operaciones de manera
gráfica e intuitiva. Es capaz de mostrar diagramas que no
aparecen en la línea de comandos, como el Explorador de Ramas.
o Integración con Microsoft Visual Studio: da acceso a las
operaciones más comunes como proteger/desproteger desde el
entorno de desarrollo, de forma cómoda y eficiente.
o Integración con Eclipse: da acceso a las operaciones más comunes
como proteger/desproteger desde el entorno de desarrollo, de
forma cómoda y eficiente.

4
 Manual de Usuario

Figura 1. Componentes y estructura de Plastic SCM

La siguiente tabla resume las plataformas soportadas por los diferentes
componentes:
Componente MS Windows Linux Mac OS X Solaris 10
Servidor X X
Cliente CLI X X X X
Cliente Gráfico X
Cliente Visual Studio X
Cliente Eclipse X X

5
 Manual de Usuario

2. Conceptos básicos de Plastic SCM

Este capítulo hará un recorrido en detalle por los diferentes elementos que
forman la plataforma Plastic SCM y servirá de base para describir las operaciones
del sistema en capítulos posteriores.

2.1. Repositorio
El repositorio es el almacenamiento principal de Plastic SCM, donde se guardan
todas las revisiones de los ficheros y carpetas, el momento en que se crearon
esas versiones, quién las creó, y las relaciones que existen entre ellas. La Figura
2 muestra todos los tipos de objetos que contiene un repositorio, y que serán
descritos en las secciones siguientes.

Figura 2. Objetos almacenados en un repositorio

Un servidor de Plastic SCM puede tener tantos repositorios como se precise,
limitado únicamente por el espacio en disco.
La primera vez que el servidor de Plastic SCM arranca tras la instalación creará
automáticamente un repositorio llamado default si no se detectan repositorios ya
creados previamente. De esta forma el usuario puede empezar a trabajar de
manera inmediata en ese primer repositorio, y crear más con posterioridad.

6
 Manual de Usuario

Para una referencia completa sobre las operaciones que se pueden hacer con los
repositorios o procedimientos de copia de seguridad, consulte la Guía de
Administración de Plastic SCM.

2.2. Ítem o elemento

Un ítem es cualquier fichero o directorio cuya evolución en el tiempo se
gestionará con Plastic SCM. Un proyecto de software a menudo está compuesto
por múltiples ficheros y directorios. Cuando esta estructura se pone bajo control
de versiones, esos ficheros y directorios se denominan ítems, indicando que será
posible ver su historial de cambios y recuperar un estado anterior. Toda la
información sobre los ítems se almacena en el repositorio (su nombre, tipo,
quién lo ha creado y todos los detalles de su historia)
Plastic SCM soporta el versionado de directorios igual que soporta el de ficheros,
característica muy importante para poder reconstruir correctamente el estado de
un proyecto en el pasado.
No todos los ficheros y directorios que existen en un proyecto deben ser puestos
bajo el control de código fuente. Por ejemplo, no tiene sentido poner los
productos de la compilación, o ficheros de configuración específicos de cada
usuario, ya que éstos son generados por los entornos de desarrollo o los
compiladores. En este sentido, Plastic SCM denomina ítems a los elementos que
están bajo control de versiones, y elementos privados a aquellos que están
junto a éstos pero no están bajo el control de versiones. Estos elementos no
existen, a efectos prácticos, para Plastic SCM pero pueden ser de utilidad para
otras herramientas como compiladores y entornos de desarrollo. La figura
siguiente muestra cómo conviven ítems con ficheros y directorios privados en el
espacio de trabajo:

Figura 3: Ejemplo de ítems bajo control de versiones y elementos

privados

7
 Manual de Usuario

2.3. Revisiones
A medida que los ítems evolucionan en el tiempo, se van creando nuevas
revisiones de los mismos. Como es lógico, algunos ítems sufrirán más cambios
que otros a lo largo del desarrollo. Plastic SCM almacena todas las revisiones de
cada ítem, de manera que es posible volver al estado de uno de estos elementos
en un momento dado. Esta evolución suele representarse como muestra la
Figura 4.

Figura 4. Ítems y revisiones

La creación de revisiones ocurre a través de las operaciones de desprotección
(check-out) y protección (check-in). Cuando se va a hacer una modificación en
un fichero, se desprotege para editarlo, y este hecho queda registrado en el
servidor de Plastic SCM.
Para crear una nueva revisión del ítem de forma que se pueda recuperar su
estado en este punto, se protege, lo que indica al servidor de Plastic SCM que
debe almacenar los nuevos contenidos del ítem. Éste almacenamiento esta
optimizado de forma que las revisiones son comprimidas de forma transparente
en el repositorio para evitar que este crezca desmesuradamente.
Las revisiones se almacenan en el repositorio, junto al resto de información del
proyecto. Entre los datos almacenados se encuentra el número de revisión, la
fecha de creación, el autor de la revisión y otros detalles que se enumerarán
más adelante en la sección de ramas.
Al conjunto de revisiones de un ítem se le denomina historia de ese ítem, y
resume la evolución de ese ítem en el tiempo. La siguiente figura muestra un
ejemplo de historia de un ítem:

Figura 5: Ejemplo de historial de un ítem

8
 Manual de Usuario

2.4. Rama (branch)

Las ramas o branches son el elemento clave en Plastic SCM, y una de las
características de diseño que le confieren una enorme potencia. En la sección
sobre revisiones, se hacía una representación de la evolución de un ítem como
ésta:

item hello.cpp

0 Revision 0. Created by Dave on 2003/06/17

1 Revision 1. Created by Ian on 2003/06/19

2 Revision 2. Created by Marc on 2003/08/25

Figura 6: Evolución (historia) de un ítem

En esta representación se está empleando el concepto de rama de manera
implícita. Una rama es un contenedor de revisiones, capaz de almacenar la
evolución de los ítems, como en la siguiente figura:

Figura 7: Revisiones de un ítem contenidas en una rama

Cuando se crea un nuevo repositorio, por defecto incluye una rama denominada
“main”, de manera que todos los ítems que se añaden al repositorio van creando
sus revisiones en ella, salvo que se indique otra cosa.
Ya se ha mencionado anteriormente que las ramas pueden contener revisiones
de más de un ítem. Ésta es, de hecho, la situación más habitual y es normal
que la rama “main” contenga muchas revisiones de prácticamente todos los
ítems, como en la figura siguiente:

9
 Manual de Usuario

Figura 8: Representación de una rama

En la Figura 8: Representación de una rama se observa cómo la rama es un
contenedor de los diferentes ítems, así como de sus revisiones (representados
como cubos blancos debajo de los amarillos, que representan al ítem),
determinando su evolución temporal. La historia de la estructura del proyecto
queda determinada por las revisiones de los directorios en el repositorio. De esta
forma, cuando un elemento se mueve de un directorio a otro, se crean
revisiones del directorio de origen y del de destino, pero no se altera el propio
ítem que se mueve. En el ejemplo de la figura, el elemento ‘master.cpp’ puede
moverse del directorio ‘src’ a otro, y sus 3 revisiones seguirán siendo las
mismas. En base a este principio Plastic SCM soporta de forma eficaz y
transparente las operaciones de refactor, sin perder la historia de los ítems que
se mueven o renombran.
Uno de los conceptos más importantes en Plastic SCM es su soporte para una
jerarquía de ramas, y la selección de contendidos que se produce entre ellas.
Este concepto es lo que se denomina Herencia de Ramas, y su comportamiento
se describe en la figura siguiente:

Figura 9: Representación de la herencia de ramas

10
 Manual de Usuario

Continuando con el ejemplo de la Figura 8: Representación de una rama, en la

Figura 9: Representación de la herencia de ramas se muestra una rama hija de
la rama principal (de ahí que se denomine ‘/main/child1’). Ésta rama contiene
únicamente revisiones de dos ítems. Esto indica que sólo esos elementos
(hello.cpp y master.cpp) han sido modificados en la rama, y por tanto la rama
sólo contiene esas revisiones.
Todas las piezas encajan cuando se mapean revisiones al espacio de trabajo, que
es donde el usuario le indica al servidor sobre qué rama (o ramas) desea
trabajar. Si el usuario desea trabajar con la rama ‘/main/child1’, cuando el
espacio de trabajo se actualice, para cada elemento, tomará la última revisión
que se encuentre en la rama ‘/main/child1’ y, si no existiera revisión en esa
rama, la de su rama padre, es decir, ‘/main’. Se puede ver una representación
de cómo se mapean las revisiones del repositorio a las revisiones que se copian
al espacio de trabajo en la figura siguiente:

Figura 10: Cómo el espacio de trabajo carga unas revisiones en

particular
El espacio de trabajo (workspace), en la Figura 10: Cómo el espacio de trabajo
carga unas revisiones en particular debe seleccionar una revisión de cada ítem, y
la regla es: “seleccionar la última revisión en la rama ‘/main/child1’”. Como la
Herencia de Ramas está presente en todo momento, al final el contenido del
espacio de trabajo es:
• master.cpp: se toma la última revisión en la rama /main/child1, como
indica la regla.
• hello.h: se toma la última revisión en la rama /main/child1, como indica
la regla.
• src: como no existen revisiones en /main/child1, se toma la última
revisión en /main, por la herencia de ramas.
• hello.cpp: como no existen revisiones en /main/child1, se toma la última
revisión en /main, por la herencia de ramas.
Un elemento puede tener revisiones en una jerarquía de ramas más complicada,
permitiéndose múltiples niveles de herencia y, sobre todo, que varios de
desarrolladores trabajen simultáneamente sobre los mismos elementos en ramas
separadas, de manera que no interfieran entre sí. En secciones posteriores se

11
 Manual de Usuario

describirá como volver a integrar estas ramas, de forma que los cambios de
múltiples autores quedan fundidos para producir releases estables del proyecto.
En Plastic SCM crear una rama no implica hacer una copia de todos los ítems del
proyecto en esa nueva rama, ni siquiera se crean enlaces. Tan sólo se crea una
entrada de rama, por lo que la creación de ramas es una operación
extremadamente eficiente y que no afecta al tamaño del repositorio.
Las representaciones anteriores resultan útiles para introducir los conceptos de
rama y espacio de trabajo al usuario que no las conoce. Sin embargo, para el
trabajo diario se emplean otro tipo de representaciones más adecuadas, como
son el árbol de versiones de un ítem concreto, o la jerarquía de ramas y sus
relaciones que ofrece el explorador de ramas.

El árbol de versiones
El árbol de versiones es la representación de la evolución de un único ítem. La
Figura 11: El árbol de versiones en la estructura del repositorio muestra dónde
encaja el árbol de versiones desde las representaciones que se han utilizado
como ejemplo:

Figura 11: El árbol de versiones en la estructura del repositorio

Ese árbol de versiones, calculado por Plastic SCM, se muestra en la figura
siguiente:

Figura 12: El árbol de versiones del ítem hello.cpp calculado por Plastic
SCM

12
 Manual de Usuario

Debido a que el propio árbol de versiones de un ítem puede crecer a lo largo de

muchas ramas, Plastic SCM ofrece una representación tridimensional del mismo,
como se muestra en esta figura:

Figura 13: Ejemplo de árbol de versiones de un elemento

El explorador de ramas
El explorador de ramas ofrece una visión temporal de la evolución de las ramas y
sus relaciones. El explorador de ramas presenta una imagen global de la
evolución del proyecto, frente a la visión mucho más localizada del árbol de
versiones, en la que únicamente se muestra la historia de un ítem.
El explorador de ramas dibuja una representación de todas las ramas presentes
en un repositorio, mostrando cuándo fueron creadas y qué periodo de vida han
tenido, que es el intervalo de fechas en el que se han creado revisiones dentro
de esa rama. Un ejemplo de este diagrama se encuentra en la figura siguiente:

Figura 14: Ejemplo del explorador de ramas

13
 Manual de Usuario

En él aparecen las ramas como barras horizontales. Las columnas corresponden

a fechas específicas en las que ha ocurrido algún evento (se ha creado la rama,
es el último día en que una rama tiene revisiones, o hay una integración –
merge- que se describirá en secciones posteriores). Las relaciones de parentesco
entre ramas aparecen como líneas rectas desde el padre hasta el inicio de las
ramas hijas. Las integraciones aparecen como líneas curvas. Para ayudar a
determinar la dirección esta operación, las líneas de merge siempre parten
horizontales del origen y van curvándose hasta el destino, donde terminan en
vertical y en un círculo.
Cuando se selecciona un elemento éste cambia de color, y se resaltan sus
relaciones con otras ramas, para ayudar a localizarlas más fácilmente.

2.5. Ramas inteligentes (smart)

El soporte de ramas inteligentes aumenta las capacidades de herencia de ramas
de Plastic SCM incluyendo la posibilidad de definir de manera dinámica las
jerarquías de ramas.
La herencia de ramas básica está muy unida al selector del espacio de trabajo,
por lo que dependiendo de la manera en la que se configure el selector, así se
comportará la herencia de ramas.
Anteriormente, al introducer la herencia de ramas se decía que cuando un
desarrollador está trabajando en una rama específica y una revision no está en
la rama, Plastic cargará esa revisión de la rama padre. La pregunta aquí es:
¿qué revisión se utilizará de ese ítem? Esta pregunta la responderá el
desarrollador al seleccionar una etiqueta como base de la rama en su espacio de
trabajo a través del selector de espacio de trabajo. Pero las ramas inteligentes
introducen una solución más sencilla: al crear una rama el usuario puede
especificar el punto (etiqueta, changeset o rama) que se utilizará como base de
la nueva rama, por lo que cada vez que Plastic necesite localizar una revisión de
un ítem en concreto en la jerarquía de ramas, irá al lugar exacto.
Las ramas inteligentes suponen un paso más en la herencia de ramas de Plastic
y una mejora en las ramas, de tal manera que son capaces de recordar qué
rama específica, changeset o etiqueta es su padre en un momento concreto.
La Figura 15 muestra un ejemplo de scenario de ramas inteligentes en el cuál
una misma rama tiene diferentes bases o puntos de herencia ya que va
evolucionando en el tiempo.
La rama realmente recuerda cada una de las configuraciones por lo que es
possible volver a un changeset en concreto y reconstruir completamente la
configuración deseada.

14
 Manual de Usuario

Una rama al evolucionar puede tener diversas bases, cada una de ellas conserva
la configuración de una herencia específica

Figura 15: Ramas definiendo la jerarquía dinámica de ramas

2.6. Workspace (espacio de trabajo)

El espacio de trabajo, o workspace, es la zona sobre la que Plastic SCM puede
mantener ítems bajo control de versiones. Sólo los ficheros y directorios que se
encuentran en el espacio de trabajo son susceptibles de ser controlados por
Plastic SCM.
A efectos prácticos, el espacio de trabajo no es más que otro directorio en el
disco del desarrollador. Para que un usuario pueda empezar a trabajar con sus
proyectos en el control de versiones, siempre necesita haber definido al menos
un espacio de trabajo. En el espacio de trabajo Plastic SCM mantendrá copias
de los diferentes ítems que componen un proyecto.
El espacio de trabajo siempre tiene una configuración que determina cuáles son
sus contenidos, marcando qué versiones de los ítems se copian desde el servidor
para trabajar sobre ellas. Normalmente indica a qué repositorio o repositorios se
conectará, y para cada uno de esos repositorios, qué ramas y puntos de partida
se emplean. Por ejemplo, esta configuración puede marcar una regla para copiar
desde el servidor al espacio de trabajo un proyecto tal como estaba cuando fue
entregado por primera vez al cliente (lo que podría ser una versión 1.0). La
figura siguiente muestra cómo el espacio de trabajo selecciona un conjunto de
versiones concreto, que son las que se copian desde el servidor.

15
 Manual de Usuario

Figura 16. Cómo se mapean revisiones a workspaces

Cuando se crea un espacio de trabajo, se asume una configuración por defecto,
que puede variarse más tarde desde los distintos clientes. Esta configuració por
defecto dicta que el espacio de trabajo use el repositorio default (creado durante
el primer arranque del servidor) y tome la última versión de sus contenidos.
Es posible, y de hecho habitual, que un desarrollador tenga más de un espacio
de trabajo en la misma máquina e incluso repartidos entre varias máquinas, a
menudo con diferentes configuraciones para trabajar de forma paralela en
diferentes tareas.

Figura 17. Cada desarrollador puede tener varios workspaces

Plastic SCM no añade ningún tipo de ficheros accesorios en una carpeta marcada
como espacio de trabajo. Otras herramientas de control de versiones tienden a
crear directorios ocultos con información extra sobre los contenidos de sus
espacios de trabajo. En el caso de Plastic SCM toda esta información es
mantenida en el servidor, lo que permite un control preciso sobre los contenidos
que maneja cada usuario.

2.7. Etiqueta (Label)

Una etiqueta es el modo de marcar revisiones para poder agruparlas según un
cierto criterio, que normalmente fija el usuario. Cuando se aplica una etiqueta,

16
 Manual de Usuario

se crea una instantánea de la situación de los ítems en el tiempo. Más tarde esa
instantánea puede ser referenciada con facilidad para identificar ese momento
específico. Una etiqueta es, en definitiva, un nombre más fácil de recordar que
se asigna a un conjunto particular de revisiones.
Las etiquetas se aplican siempre a las revisiones de los ítems que se encuentren
actualmente en el espacio de trabajo, y pueden aplicarse a todos los ítems, o
sólo a algunos de ellos, según las necesidades.
La Figura 18 muestra dos labels: Label 0 y Label 1. Ambas etiquetas se aplican a
diferentes revisiones de diferentes ítems. La etiqueta Label 0 simplemente marca
la revisión 0 del primer ítem. Sin embargo Label 1 se usa para agrupar juntas
varias revisiones de diferentes ítems.

Figura 18. Etiquetas aplicadas a revisiones

Para usar una etiqueta, el primer paso consiste en crearla, indicando en qué
repositorio y el nombre que usará.
Las etiquetas se usan por muchos motivos diferentes. Se pueden agregar a
ciertas revisiones simplemente para resaltar algo, o pueden usarse para
gestionar el proceso de desarrollo, ayudando a crear entregas (releases) y líneas
base (baselines).

17
 Manual de Usuario

3. Operaciones de Plastic SCM

En este capítulo se describirán las principales operaciones de control de

versiones que Plastic SCM puede realizar. Estando familiarizado con otros SCM o
sistemas de control de versiones, muchas de las operaciones resultarán
familiares, quizá con algunos cambios de nombre.

Figura 19. Operaciones básicas de control de versiones

Por cada operación se muestran algunos ejemplos de uso desde la interfaz de
línea de comandos. Se puede obtener una ayuda más detallada de cada
comando a través del modificador ‘--help’:

18
 Manual de Usuario

cm help

cm help comando

cm comando --help

3.1. Creando un repositorio

Un repositorio llamado default se crea durante el primer arranque del servidor.
Usando este repositorio los usuarios pueden empezar a trabajar más fácilmente
ya que sólo necesitarán crear un espacio de trabajo. Aquí se creará uno nuevo y
es el que se usará en el resto del ejemplo.

Desde la interfaz gráfica 
1. En el menú Repositorios / Crear nuevo repositorio…
2. Introducir un nombre descriptivo, y el servidor en el que se creará.

Figura 20: Diálogo de creación de repositorio

Desde la línea de comandos 

cm mkrep servername:8084 project3

3.2. Crear espacios de trabajo

La primera vez que un desarrollador arranca la herramienta GUI, si no se detecta
ningún espacio de trabajo, aparecerá un diálogo de creación, como muestra la
Figura 54: Creando un espacio de trabajo. Por defecto los espacios de trabajo
apuntan al repositorio default, y a la rama main.

19
 Manual de Usuario

Desde la interfaz gráfica 
1. En el menú Workspaces / Crear nuevo workspace.
2. Introducir un nombre descriptivo, la ruta y el servidor en el que se creará.

Figura 21: Creando un espacio de trabajo

Desde la línea de comandos 

cm mkwk dave_view c:\projects\view1

3.3. Add (Añadir)

Una vez que un repositorio ha sido creado (un repositorio denominado default se
crea siempre durante la instalación), la primera operación será añadir ficheros y
directorios al control de versiones.
La operación de añadir (add) le indica al sistema que un conjunto de ficheros y
directorios serán controlados por Plastic SCM. La operación de añadir crea la
información necesaria en el repositorio para que esos ítems puedan ser utilizados
posteriormente.
Cuando se inicia una operación add, todos los ítems se añaden en la rama que
se encuentre configurada en ese momento en las reglas del selector.

Cómo ignorar determinados ítems 
Plastic SCM puede ignorar determinados patrones de ficheros o directorios para
que no sean añadidos al control de versiones cuando se realiza un add. Estos
patrones se definen en un fichero llamado ignore.conf. Este fichero se puede
colocar en varias ubicaciones y dependiendo de donde se ubique, diferirá su
ámbito de aplicación.
- Si se coloca en la raíz del espacio de trabajo, los patrones de exclusión se
aplicaran sólo en ese espacio de trabajo y no se tendrán en cuenta ninguno
de los ficheros de exclusión que se encuentren en las demás ubicaciones.
- Si se coloca en el directorio de configuración de plastic de un usuario (leer
más abajo), se tendrá en cuenta para todos los espacios espacios de trabajo

20
 Manual de Usuario

de ese usuario (no se tendrá en cuenta para aquellos espacios de trabajo

que ya tenga un fichero de exclusiones propio).
El contenido del fichero ignore.conf consta de un patrón por línea. En los
patrones se pueden especificar caracteres comodín (* y ?) con el mismo
significado que en la línea de comandos. Las líneas que empiezan por el carácter
# se interpretan como un comentario.
Cada entrada en este fichero especifica una ruta completa al ítem que se ha de
ignorar. Si se desean ignorar todas las ocurrencias de una entrada, es necesario
utilizar caracteres comodín.
El directorio de configuración de un usuario se encuentra en:
Para systemas Windows:
C:\Documents and Settings\user\Configuración Local\Datos de Programa\plastic

Para sistemas no Windows:

$HOME/. plastic

Este es un ejemplo del fichero ignore.conf file (El carácter # indica comentario):

#Patrones ignorados por Plastic SCM

*/bin (a todos los direcotorios “bin”)

*processes.conf (ignora todos los ficheros ubicados en el

workspace cuyo nombre es processes.conf)

*.suo (ignora todos los ficheros con extensión .suo)

*private* (ignora todos los ficheros y directorios ubicados en el

workspace que contienen “private” en sus nombres.)

Notas:
- Si se incluye una línea como “*/bin” en el archivo ignore.conf, solamente se
ignorarán los directorios /bin; cuando se trate de realizar un add recursivo, se
tratará de agregar los ítems contenidos en /bin y Plastic SCM se quejará. La
forma correcta de ignorar un directorio y todo su contenido es: */<dir_name>*;
así por ejemplo: */bin*.
- Pueden utilizarse paths en formato UNIX (“/”) o Windows (“\”)
independientemente de la plataforma en la cual se está trabajando.

Tipos de items (binario/texto) 
Plastic SCM reconoce automáticamente el tipo de un fichero, por su extensión.
Pero algunas ocasiones, tipos de ficheros menos comunes son interpretados
como contenido binario cuando en realidad son texto. El usuario puede asociar
extensiones de fichero a un tipo fijo (binario o texto). Para ello ha de definir un
fichero llamado filetypes.conf y colocarlo en el directorio de configuración del
usuario (ver punto anterior)
Este es un ejemplo del contenido de un fichero filetypes.conf file. (El character #
indica comentario):

#Tipos de fichero definidos para PlasticSCM.

21
 Manual de Usuario

#Sintaxis: <extension>:<type>. Type can be 'txt' or 'bin'.

#Examples:

.java:txt

.cpp:txt

.jpg:bin

.psd:bin

Tras una operación de añadir, tanto ficheros como directorios permanecen

desprotegidos (checked out). Por tanto la operación añadir no provoca que los
datos viajen a través de la red, simplemente añade metadatos al repositorio. La
operación de añadir puede realizarse tanto desde la línea de comandos, como
desde la herramienta GUI o desde las integraciones con los diferentes entornos
de desarrollo (IDE). El último caso presenta la ventaja de que el entorno se
encarga de añadir sólo los ficheros correctos, dejando fuera elementos
temporales, configuraciones locales, binarios generados y elementos intermedios
de compilación. En la figura siguiente, se han añadido algunos ítems desde
Microsoft Visual Studio. Los elementos en verde con un punto rojo se encuentran
añadidos y desprotegidos. Cuando se protejan aparecerán en color verde sin el
punto.

Figura 22: Elementos recién añadidos desde Visual Studio

22
 Manual de Usuario

Añadiendo ítems desde la línea de comandos 
Para importar un proyecto en Plastic SCM, copie los contenidos dentro del
directorio del workspace, y añádalos de manera recursiva con el comando:

cm add –R *

Para añadir un elemento aislado, simplemente:

cm add nombre_del_ítem

Para añadir un elemento, haciendo checkout del padre de manera automática:

cm add –-coparent nombre_del_ítem

Desde la integración con Visual Studio 
Una vez el proyecto ha sido copiado en el espacio de trabajo, y está abierto en
Visual Studio:
1. Seleccionar la solución en el Explorador de Soluciones
2. Botón derecho, opción de menú “Agregar Solución al control de código
fuente”

Figura 23: Agregar solución al control de código fuente

La integración con Visual Studio se encarga de proteger automáticamente los
ítems tras añadirlos a Plastic SCM. Cuando los ítems se encuentran bajo el
control de código fuente, aparece un candado a su lado indicando que su estado
es ‘protegido’.

23
 Manual de Usuario

Figura 24: Elementos protegidos

Los proyectos web, en especial con Visual Studio 2005, tienen un
comportamiento ligeramente distinto. Puede encontrar más información sobre el
trabajo con proyectos web en Visual Studio en el sitio web de Códice
(www.codicesoftware.com) en la sección de Soporte.

Desde la integración con Eclipse 
Asumiendo que se ha completado la instalación del plug-in para Eclipse, y se ha
creado un espacio de trabajo de Plastic que contiene al espacio de trabajo del
proyecto de Eclipse, añadir un proyecto a Plastic SCM consiste en dos pasos.
Desde el explorador de paquetes, o desde el navegador, seleccionar el proyecto,
botón derecho, en el menú de contexto, seleccionar ‘Team’, y dentro de éste,
‘Compartir Proyecto’.

Figura 25: Agregar a control de versiones en Eclipse

Una vez compartido el proyecto, aparecen las opciones para añadir los ficheros
al control de versiones. Desde el mismo fichero de proyecto es posible ahora
añadir recursivamente todos los elementos del proyecto. Con el fichero de
proyecto seleccionado, botón derecho, menú ‘Team’, opción ‘Añadir a Plastic
SCM recursivamente’.

24
 Manual de Usuario

Figura 26: Añadir a Plastic recursivamente

Tras esta operación, los elementos del proyecto se han añadido como ítems al
control de versiones (se puede ver una marca al lado de cada uno de ellos).
Cuando se añaden, esos ítems se encuentran desprotegidos, así que para
finalizar la operación de añadir, es necesario protegerlos. Para ello, con el mismo
fichero de proyecto todavía seleccionado, botón derecho, menú ‘Team’ y
‘Proteger recursivamente’.

Figura 27: Proteger recursivamente desde Eclipse

Pueden encontrarse más detalles sobre la configuración inicial y el uso del Plugin
de Eclipse en una sección posterior.

3.4. Check in (proteger)

La operación proteger o check-in sirve para almacenar los cambios realizados en
un ítem en el servidor. La protección siempre se realiza después de una
operación de check out o de add (es necesario recordar que tras una operación
de añadido, add, los ítems siguen en estado check out).
Durante la operación de protección el sistema comprobará si los datos del fichero
o directorio han cambiado. Si el usuario intenta proteger un fichero o un
directorio que no han sido modificados, el sistema emitirá un aviso. Por defecto
será necesario hacer modificaciones antes de hacer check in. En caso de que se
desee crear una revisión igual a la anterior, se podrá usar la opción de check in
forzado.
La operación proteger crea la revisión en la misma rama en la que se especificó
que ocurriría la desprotección, y es una operación atómica. Esto significa que la
operación o bien se completa satisfactoriamente protegiendo todos los
elementos que el usuario había indicado, o bien no se protege ninguno,
quedando pendientes de protección.
Así se garantiza que un error en algún punto de la protección no crea un estado
inconsistente, ya que todos los ítems que son protegidos en una única operación
de check-in comparten un identificador denominado número del conjunto de
cambios o changeset number. Este identificador es impreso al final de una
protección tanto en la interfaz de línea de comandos como en la ventana de log

25
 Manual de Usuario

de la interfaz gráfica. Este número es una fórmula más para agrupar cambios
que Plastic SCM pone a disposición del usuario. Dado que normalmente un
cambio (por ejemplo un bugfix) afecta a varios ítems, el changeset permite
agruparlos.
Es posible ver qué ítems hay en un changeset concreto a través del sistema de
consultas, descrito en una sección posterior.

Desde la interfaz gráfica 
Cualquier ítem desprotegido se puede proteger desde su menú de contexto,
tanto en una vista de ítems como en la vista de desprotecciones, seleccionando
la opción “proteger”.

Protegiendo ítems desde la línea de comandos 
Para proteger un ítem que se encuentra desprotegido (en checkout) desde la
línea de comando, emplee el comando ‘checkin’, o abreviadamente, ‘ci’

cm ci ítem_desprotegido

Es posible proteger recursivamente todo un directorio y sus contenidos, aunque

la operación mostrará un aviso para aquellos que no están desprotegidos o no
están bajo control de versiones

cm ci –R *

Para proteger un ítem, desactivando la comprobación de contenido

cm ci --nchk ítem_desprotegido

Para listar todos los ítems contenidos en un changeset:

cm find revision where changeset = número_de_changeset

Desde la integración con Visual Studio 
Es posible proteger uno o varios ítems desprotegidos marcándolos en el
Explorador de Soluciones y seleccionando “Proteger” en su menú de contexto.
Adicionalmente, se puede proteger desde la lista de protecciones pendientes, la
cual permite especificar el comentario (cuando el botón “Comentarios” ha sido
activado):

26
 Manual de Usuario

Figura 28: Lista de protecciones pendientes antes de proteger los ítems

Desde la integración con Eclipse 
Desde eclipse es posible proteger todos los ítems desprotegidos bajo una carpeta
de manera recursiva, o bien cada ítem individual. Para proteger recursivamente,
seleccionar el elemento, botón derecho, menú Team, opción ‘Proteger
recursivamente’. Ésta acción protegerá todos los ítems desprotegidos que se
encuentren bajo el elemento seleccionado. Para proteger sólo un ítem
desprotegido se han de seguir los mismos pasos pero con la opción ‘Proteger’.

3.5. Update (obtener)

La operación de update 1 descarga ficheros y directorios a un espacio de trabajo
teniendo en cuenta sus reglas de selección. Cuando se acaba de crear un
espacio de trabajo nuevo, se hace un update para poblarlo por primera
vez. En condiciones normales, se hace un update para copiar al espacio de
trabajo las últimas versiones de los ítems que corresponden a su configuración.
Cuando se cambia la configuración del espacio de trabajo (alterando el selector,
o cambiando la rama o etiqueta a las que apunta), se realiza un update para que
el sistema calcule qué revisiones han de descargarse.
La operación de update recorre toda la estructura del proyecto según el selector
actual, y calcula si necesita traer versiones diferentes de las que hay al espacio
de trabajo. Se puede hacer que la operación de update siempre sobrescriba las
versiones existentes en el espacio de trabajo, independientemente de sus
contenidos, a través del modificador

cm update –-forced .

Ítems modificados en el espacio de trabajo

En ocasiones, la operación de update puede mostrar un mensaje como el
siguiente:

1
La operación de update es similar a una operación de checkout en sistemas
CVS y Subversion. En Plastic SCM descargar y desproteger revisiones son
operaciones separadas.

27
 Manual de Usuario

El ítem xxx se ha modificado en el espacio de trabajo actual. No

se sobrescribirá.

Esto es debido a que los contenidos del ítem en cuestión han sido modificados
sin haber indicado a Plastic SCM que hiciera una desprotección, y la operación de
update por defecto no sobrescribe el fichero, ya que podría contener cambios
importantes. Si quiere que esos cambios formen parte del historial del ítem,
desproteja el ítem y protéjalo con los cambios. Si sabe con certeza que no ha
habido ningún cambio en el ítem que está dando el aviso, y quiere evitarlo en el
futuro, puede forzar el update, a través del modificador --forced que se ha
introducido en el apartado anterior, sobrescribiendo el ítem con la versión que le
correspondería en todo caso.

Ítems marcados como .unloaded

A consecuencia de la operación de update, puede ocurrir que en las nuevas
versiones que se están cargando al espacio de trabajo se hayan eliminado items.
En este caso, Plastic SCM sigue la regla de no borrar nada, por lo que en vez de
borrar los elementos que se perderían, los renombra con la extensión .unloaded
con lo que se convierten en elementos privados. De esta manera el contenido no
se pierde, por si hay algo importante, pero con un nombre diferente para que no
entren en conflicto con otras herramientas.

Resguardo automático de desprotecciones (Checkout

shelving)
Plastic SCM introduce una característica muy conveniente cuando se trabaja con
varias ramas en el mismo espacio de trabajo. En el caso de que tras un cambio
del selector de un espacio de trabajo una operación de update necesite
sobrescribir un ítem que se encuentra desprotegido, Plastic SCM salvará
automáticamente el contenido de esa desprotección en el servidor antes de
sobrescribirla, de forma que sus contenidos son preservados. No implica el que
se haga una protección ni se cree una nueva revisión como tal. Más tarde esos
ítems pueden ser recuperados.
Imagine que está trabajando sobre la rama ‘/main/tarea4’, en la que tiene
algunos ítems desprotegidos.

28
 Manual de Usuario

Figura 29: Ficheros desprotegidos antes del update

Si cambia la configuración de su espacio de trabajo para que apunte a
‘/main/tarea6’, la operación de update normalmente traerá las versiones que
están en main de los ficheros que usted había modificado en ‘/main/tarea4’, ya
que esos ficheros no están en ‘/main/tarea6’. Esta operación se ve reflejada en
el log.

Figura 30: Protección de ficheros en check out

Plastic SCM guardará esas desprotecciones en el servidor mientras usted
continúa trabajando en ‘/main/tarea6’. Puede comprobar que sus
desprotecciones aún están pendientes a través de la vista de ‘protecciones
pendientes’ en la interfaz gráfica. Aparecen con un signo de exclamación,
indicando que son desprotecciones que no están en el espacio de trabajo.

Figura 31: Ficheros desprotegidos en la rama

29
 Manual de Usuario

Cuando vuelva a apuntar su espacio de trabajo a ‘/main/tarea4’, la operación de

update recuperará los contenidos de sus desprotecciones y las indicará como tal,
ahora en verde con un punto rojo, porque ya se encuentran en el espacio de
trabajo.

Figura 32: Recuperación de contenidos del check out

Update paralelo
La operación de update emplea varios hilos o threads. Mientras que este modo
aumenta el rendimiento en la mayoría de escenarios, existen unos pocos en los
que puede resultar interesante emplear un solo hilo para reducir, por ejemplo, la
cantidad de conexiones que realiza el cliente, quizá en entornos con poco ancho
de banda entre cliente y servidor. Para llevar a cabo una operación de update
que no emplee varios hilos se emplea el modificador –noparallel desde la interfaz
de línea de comandos.

cm update . --noparallel

3.6. Check out (desproteger)

La operación desproteger sobre un ítem indica al control de versiones que ese
ítem va a ser modificado. Se desprotegen los ficheros cuando se van a hacer
cambios en su contenido, y se desprotegen los directorios cuando se van a
añadir, mover o eliminar ítems que contienen.
Cuando un ítem se desprotege, aparece la marca ‘CO’ (de check out) en la
interfaz de línea de comandos, y un punto rojo en el icono del ítem en el caso de
la interfaz gráfica. En caso de que el espacio de trabajo apunte a una rama hija
(por ejemplo, /main/tarea4, hija de /main) y no exista previamente una revisión
de ese ítem en esta rama hija, la desprotección creará la primera en esa rama,
desde la revisión actual en el espacio de trabajo. En el siguiente ejemplo se
han desprotegido los ítems Form1.cs y Form1.Designer.cs, que se encontraban
en la rama /main, con el espacio de trabajo apuntando a la rama /main/tarea4:

11/06/2007 19:46 dir br:/main#0 .

11/06/2007 19:46 txt br:/main/tarea4#CO CO Form1.cs
11/06/2007 19:47 txt br:/main/tarea4#CO CO Form1.Designer.cs
11/06/2007 19:46 txt br:/main#0 Program.cs
11/06/2007 19:46 dir br:/main#0 Properties
11/06/2007 19:46 txt br:/main#0
WindowsApplication1.csproj

Cuando un fichero es desprotegido el atributo de sólo lectura es eliminado, de

modo que el usuario puede escribir sobre él. Este atributo es restablecido cuando
más tarde se proteja de nuevo.

30
 Manual de Usuario

Desde la interfaz gráfica 
Cualquier ítem protegido se puede desproteger desde su menú de contexto
desde la vista de ítems, seleccionando la opción “desproteger”.

Desprotegiendo ítems desde la línea de comandos 
Para desproteger un ítem cualquiera:

cm co nombre_del_ítem nombre_de_otro_ítem

Para desproteger de manera recursiva un directorio y todos sus contenidos:

cm co –R directorio/*

Desproteger todos los ítems leídos desde la entrada estándar:

cm co –

Desde la integración con Visual Studio 
La integración con Visual Studio desprotege de manera automática los ítems en
el momento en que empiezan a modificarse. Cuando un ítem está desprotegido,
el candado al lado de ese ítem en el Explorador de Soluciones se reemplaza por
una marca de edición.

Figura 33: Detalle de elemento desprotegido en Visual Studio

Visual Studio puede configurarse para preguntar antes de desproteger un ítem,
desde el menú de opciones. Cuando esta preferencia esta activa, al desproteger
un ítem aparece este diálogo

31
 Manual de Usuario

Figura 34: Diálogo de desprotección de Visual Studio 2003

Desde la integración con Eclipse 
Por defecto el Plugin de Eclipse está configurado para desproteger los elementos
de manera automática cuando empiezan a modificarse, o al hacer una operación
de refactor.

Detalles internos de la operación de check out

A nivel interno, desproteger un elemento tiene el efecto de crear una nueva
revisión especial y vacía en el servidor. La Figura 35 muestra cómo esta revisión
se crea cuando se ejecuta una operación de check out. Al hacer posteriormente
la protección o check in, la revisión se convertirá en una revisión convencional
que tendrá datos asociados.

Figura 35. Creación de una revisión durante la operación de check out

El árbol de versiones tridimensional muestra las desprotecciones como un cubo
morado, frente a los cubos azules que representan revisiones normales.
Este mecanismo hace posible trazar dónde se están realizando las
desprotecciones de cada usuario y es la base para el check out shelving que se
ha descrito en el apartado dedicado al update.

32
 Manual de Usuario

3.7. Viendo las protecciones pendientes

Plastic SCM controla qué ítems se encuentran desprotegidos para cada usuario
en cada espacio de trabajo, y es posible listarlos desde los diferentes clientes.

Desde la interfaz gráfica 

Figura 36. Listar las revisiones desprotegidas

Desde la línea de comandos 
Mostrar los ítems desprotegidos del espacio de trabajo actual

cm findcheckouts
cm fco

Mostrar los ítems desprotegidos de todos los espacios de trabajo

cm fco --all

Mostrar sólo el nombre de los ítems desprotegidos sin información de ramas o de

otro tipo

cm fco –format={4}

Desde la integración con Visual Studio 
En Visual Studio 2003 sólo existe un punto de entrada para mostrar esta lista, y
se accede desde el menú de contexto de cualquier elemento desprotegido,
opción “Mostrar protecciones pendientes”.

Figura 37: Opción "Mostrar protecciones pendientes" en Visual Studio

33
 Manual de Usuario

3.8. Uncheckout (cancelar una desprotección)

Cuando se ha desprotegido un ítem, es posible cancelar esa desprotección.
Internamente, la operación uncheckout realiza una cancelación del checkout, y
un update de ese ítem. Cuando se trata de un fichero, esto implica que se
restaura el fichero a la revisión que selecciona reglas del espacio de trabajo.
Cuando se trata de un directorio ocurre lo mismo, aunque en este caso sólo se
actualizan los nombres de los ítems que contiene, es decir, se actualizan los
posibles renombrados, y se manejan los borrados o añadidos consecuencia de la
operación de update a la revisión que corresponde.

Desde la interfaz gráfica 

Figura 38: Cancelar una desprotección desde la línea de comandos

Cancelando desprotecciones desde la línea de comandos 
Cancelar la desprotección de un ítem cualquiera:

cm unco nombre_del_ítem

Cancelar las desprotecciones de todos los elementos pendientes de protección

(cancelar todos los checkouts en el espacio de trabajo actual:

cm fco --format={4} | cm unco –

El comando ‘findcheckouts’ o, abreviadamente ‘fco’, imprime información de los

checkouts del espacio de trabajo actual, o de todos los espacios de trabajo. El
modificador --format permite especificar el formato de lo que se imprimirá, en

34
 Manual de Usuario

este caso {4} indica que sólo se imprima el nombre del ítem. El – le indica al
comando uncheckout que lea los ítems desde la entrada estándar.

3.9. Crear una rama

Como ya se ha mencionado con anterioridad, Plastic SCM crea por defecto una
rama llamada ‘/main’ en cada repositorio. Para poder usar otras ramas, es
necesario crearlas primero.

Crear una rama desde la interfaz gráfica 
Desde la vista de ramas, se selecciona la rama padre en la que se creará la
nueva rama, botón derecho y “Crear rama hija”:

Figura 39: Creando una rama hija desde la interfaz gráfica

Crear una rama desde la línea de comandos 
Las ramas son creadas con el comando ‘mkbranch’ como en el siguiente
ejemplo, que crea una rama llamada ‘child1’ cuyo padre es la rama ‘/main’.

cm mkbranch br:/main/child1

Las barras ‘/’ separan los niveles de la jerarquía de ramas. Una rama tiene una
sola rama padre y puede tener varias ramas hijas.

3.10. Merge (integración)

La operación de merge o integración es la encargada de mezclar contenidos que
han evolucionado por separado en Plastic SCM. Por ejemplo, cuando dos
desarrolladores han modificado los ítems en ramas separadas y se pretende
juntarlas de nuevo o cuando dos desarrolladores trabajan sobre la misma rama
pero han modificado el mismo fichero por separado y hay que reconciliar los
cambios de ambos.

35
 Manual de Usuario

La operación de merge es tradicionalmente una de las más complejas en los

sistemas de control de versiones. Sin embargo, Plastic SCM trata de mantener
esta complejidad alejada del usuario al máximo, resolviendo internamente tantos
conflictos como le es posible.
Una operación de merge comprobará qué diferencias hay desde una
rama (que se denomina origen) con los contenidos actuales del espacio
de trabajo (que será el destino). Si el origen del merge es una rama, se
tomarán las últimas versiones de los ítems en la rama para calcular cuáles de
ellos necesitan ser mezclados. En la operación de merge, por tanto, siempre se
elige un origen, y se compara con el contenido actual del espacio de trabajo,
que se denomina destino. En Plastic SCM, el destino siempre es el contenido
(las versiones de los ítems) que se encuentran en el espacio de trabajo.
Plastic SCM determinará con precisión qué ítems han sido modificados en el
origen respecto al destino, y propondrá una lista con ellos. Un ejemplo de la lista
de candidatos a merge puede verse en la figura siguiente:

Figura 40: Ejemplo de ítems que necesitan merge

En esta lista aparecen los nombres de los ítems que necesitan merge, tanto
ficheros como directorios, el tipo de conflicto y los contribuidores implicados. Las
secciones siguientes explicarán cada uno de estos puntos en detalle.

Tipos de conflicto de merge

Cuando se está realizando una operación de merge, el objetivo es reconciliar
cambios que han ocurrido a la base de código por caminos separados. En este
contexto se pueden dar dos tipos de conflictos:
• Copy merge: el ítem se ha añadido por primera vez al control de
versiones en el origen, y el merge no necesita comprobar los contenidos,
tan sólo copiarlo al destino.

36
 Manual de Usuario

• Merge: el ítem ya existía tanto en el origen como en el destino de la

operación de merge, y hay que reconciliar cambios. En este caso, se
examina de dónde vienen los cambios, que es lo que indica la columna
contribuidores.

Contribuidores
Los contribuidores son las revisiones del ítem que intervienen en el merge.
Siempre hay un origen del merge, que es la revisión de la rama que se está
integrando. Un destino, que es la revisión que hay en el espacio de trabajo
actual, y una base, que es la revisión de la que partieron originalmente las dos
anteriores. La siguiente figura muestra de dónde viene cada revisión:

Figura 41: Revisiones implicadas en una operación de merge

En esta figura, el espacio de trabajo del usuario apunta a la rama br:/main y se
pretende incorporar a esa rama los contenidos de la rama br:/main/child1. Los
contribuidores serán:
• Origen (source): /main/child1#1
• Destino (destination): /main#5
• Base: /main#4
En la Figura 41: Revisiones implicadas en una operación de merge también se
representa que el resultado de la operación de merge creará una nueva revisión
/main#6, una vez se haga el merge, y se proteja el resultado.
Teniendo claros estos conceptos, la columna ‘Contributors’ del diálogo de merge
puede tener éstos valores:
• Source: los cambios vienen únicamente del origen. No hay revisiones
nuevas en el destino después de la revisión base. Este tipo se resuelve de
manera automática aplicando todos los cambios del origen en el destino.
• Destination: los cambios vienen únicamente del destino. Es el caso
opuesto al anterior, y también se resuelve de manera automática.
• Both (ambos): han aparecido revisiones después de la base tanto en la
rama de origen como en la de destino. Este tipo de merge puede ser
automático o necesitar la intervención del usuario, según éstos criterios:
o Si se trata de un fichero y es de texto, los conflictos se resolverán
automáticamente cuando los cambios ha ocurrido en zonas que no
se solapan entre sí. Si se han cambiado líneas coincidentes en
ambas revisiones, aparecerá la herramienta gráfica de merge, que

37
 Manual de Usuario

permite reconciliar los cambios. Esta herramienta se describe en

una sección posterior.
o Si se trata de un fichero de tipo binario, aparecerá en todo caso la
herramienta de merge binario, que permitirá elegir cuál de las
revisiones implicadas se guarda como resultado del merge. Es
posible definir herramientas de merge asociadas a diferentes
extensiones de ficheros en la configuración de cada cliente.
o Si se trata de un directorio, el sistema intentará reconciliar los
cambios que han ocurrido en las dos revisiones de origen y
destino. Normalmente esta reconciliación es automática, aunque
existen cuatro escenarios en los que se requerirá la intervención
del usuario, al que se presentará un asistente para reconciliar los
cambios. Excepto estos cuatro casos, todo el merge de directorios
ocurre de forma automática.
ƒ Dos ítems se han renombrado al mismo nombre en el
origen y el destino
ƒ Un ítem se ha renombrado de manera diferente en el origen
y el destino
ƒ Se han añadido dos nuevos ítems con el mismo nombre en
el origen y en el destino
ƒ Un ítem se ha renombrado con el mismo nombre con el que
se ha añadido uno nuevo en origen o destino.

Merges desde la misma rama

Es posible que un merge sea necesario usando la misma rama como origen y
destino. Esto sucede cuando un fichero ha sido modificado desde dos espacios de
trabajo diferentes apuntando a la misma rama.

Figura 42. Situación que necesitará un merge desde la misma rama

En este caso será necesario que ‘developer2’ primero mezcle sus cambios con los
que hay en la rama, introducidos por ‘developer1’ y de los que ‘developer2’ no
ha sabido nada hasta la hora de proteger su trabajo.

38
 Manual de Usuario

Figura 43. Ejemplo básico de merge, merge terminado

Una vez que ‘developer2’ ha completado el merge de los ítems necesarios, puede
proteger sus cambios manteniendo la integridad de la base de código.

Merges desde ramas diferentes

El caso de merge más habitual es, no obstante, aquel en que la rama de origen
es diferente de la rama de destino (que es a la que apunta el espacio de
trabajo). En la figura siguiente se muestra un posible escenario, en el que dos
desarrolladores han creado ramas para trabajar en paralelo (/main/branch001 y
/main/branch002) partiendo de un mismo punto en la rama principal (la revisión
/main#1). La figura representa únicamente un ítem en particular (boo.c), si bien
es corriente al trabajar con ramas que se creen revisiones de numerosos ítems.

Figura 44: Escenario de desarrollo paralelo

La Figura 45. muestra cómo los desarrolladores van trabajando por separado,
haciendo modificaciones sobre el ítem, cada uno en su rama, sin interferir con el
otro. Pueden hacer tantas protecciones intermedias como deseen ya que sus
cambios sólo son vistos por ellos mismos.

39
 Manual de Usuario

Figura 45. Los desarrolladores evolucionan las revisiones

Cuando el desarrollador termina sus modificaciones, los cambios están listos
para ser integrados en la rama principal, de manera que serán visibles por los
demás desarrolladores.
A la hora de hacer la integración, se parte de un espacio de trabajo que apunta a
‘br:/main’ (ya que el destino de la operación de merge siempre es el contenido
actual del espacio de trabajo), y se incorporan las ramas una a una. De esta
forma se pueden incorporar tantas como se desee. El resultado para el ítem
‘boo.c’ aparece representado en la figura siguiente.

Figura 46: Las dos ramas han sido integradas

En esta representación no se ha hecho checkin después de cada operación de
merge, por lo que todos los merges han ido a la misma revisión (en este caso,
/main#2).

Merge desde una rama y una etiqueta

Aunque posiblemente el caso de merge más habitual sea desde ramas distintas,
cuando se vio se describía como los últimos cambios de la rama origen eran
incorporados en el espacio de trabajo. En ocasiones puede que no interese hacer

40
 Manual de Usuario

el merge del último contenido de la rama sino de aquel que previamente se ha

etiquetado. Esto sucede cuando deseamos incorporar los cambios de una rama
en la que se ha seguido, o se sigue, trabajando y queremos un contenido
concreto que se sabe que funciona justo como se quiere.
Para conseguir este se puede particularizar el merge de una rama, para que en
lugar de tomar la última revisión de cada elemento coja una revisión concreta
que se encuentra etiquetada en la rama.
La figura representa únicamente un ítem en particular (boo.c), sobre el que se
ha seguido trabajando en la rama y del cual queremos recuperar la versión
etiquetada.

Figura 47: La revisiones etiquetadas en la rama han sido integradas

Tal y como puede verse, la revisión que es incorporada en el merge no es la
última de la rama, cómo ocurría en el caso de del merge desde ramas
diferentes, sino que es la revisión que estaba etiquetada.

Merge desde una etiqueta

Hasta ahora hemos visto como incorporar los cambios de una rama, en sus
distintas versiones, en el espacio de trabajo. Puede darse el caso que interese
incorporar los cambios que previamente han sido etiquetados con independencia
de en que rama se encuentren dichos cambios. La diferencia entre este caso y el
merge desde una rama y una etiqueta es que mientras en el anterior sólo se
cogían aquellos elementos etiquetados en esa rama, aquí se cogen todos los
elementos con esa etiqueta con independencia de la rama en la que se
encuentren.
Trabajando con múltiples ramas, puede resultar muy útil cada vez que se genera
una nueva release. Cuando se genera una release, es aconsejable que sea
etiquetada para poder volver a ella. Tras concluir la release y una vez esta
probada y etiquetada, aquellos desarrolladores que estén trabajando deberán
incorporar los cambios realizados en la release en su rama. Para hacerlo se hará
un merge desde la etiqueta de la release.

41
 Manual de Usuario

A esta operación que consiste en actualizar el contenido de la rama de

trabajo para qué deje de basarse en la release antigua y pase a basarse en la
nueva release se le denomina rebase.

También puede interesar incorporar un cambio concreto que debido a su

importancia u a otras razones ha sido etiquetado.

Merge desde un changeset

Cuando se describió el funcionamiento de la operación de check in, se habló de
que todos aquellos elementos que se protegían al mismo tiempo recibían un
identificador denominado changeset. Por medio te este changeset podríamos
hacer referencia a todos aquellos elementos que formaban parte de un cambio.
Gracias a que el cambio puede ser identificado de esta manera es posible
incorporar ese cambio si se hace un merge de ese changeset. Al igual que en el
caso del merge desde una etiqueta, no se depende de la rama donde se
encuentra el contenido del changeset. Dado que lo único que necesitamos para
acceder a todos los elementos que forman ese cambio sin ambigüedad es el
changeset.

Para que el merge desde un changeset tenga sentido, cuando se realice

un cambio (se creo nueva funcionalidad, se corrigió,…) todos los elementos
que formaban parte de él deben de protegerse a la vez y no ir protegiendo los
distintos elementos que los componen de forma separada. Si un cambio está
dividido entre varios changeset sería necesario hacer el merge de todos y
cada uno de ellos, por lo que esta opción pierde su utilidad.

Merge desde una revisión

Hasta ahora siempre que se ha hablado del origen del merge este contenía más
de un elemento, o al menos podía contenerlos. Si sólo se quiere incorporar los
cambios de un elemento, en concreto el contenido que tenía un elemento en una
revisión concreta se emplearía este método.
A diferencia de los anteriores con este método sólo se incorporará el contenido
de la revisión indicada por el usuario. Por tanto será el usuario el que decida que
elemento ha de ser mezclado en lugar de ser el sistema el que los busque en
base a alguno de los criterios dado (changeset, rama,…).
Si se quisiese hacer de más de un elemento, o se usa uno de los métodos
anteriores, o se hace el merge de manera individual para cada uno de esos
elementos. Por lo tanto para hacer el merge de 2 elementos habría que hacer el
merge dos veces de forma independiente, para 3 elementos 2 y así
sucesivamente. Salvo que el merge sea de un elemento o de muy poco
elementos, o bien que los elementos de los que se desea hacer el merge no este
relacionados de ninguna manera, éste método no es el más conveniente.

Haciendo merge desde la línea de comandos 
La operación de merge siempre toma como destino el contenido del espacio de
trabajo. Por eso es interesante hacer una operación de update antes de
comenzar con un merge para asegurar que los contenidos del espacio de trabajo
son los apropiados.
Para actualizar el contenido del espacio de trabajo a las versiones que deben
tener, se usa este comando, desde la raíz del espacio de trabajo:

42
 Manual de Usuario

cm update .

El comando ‘mergebranch’ toma como argumento principal una especificación de

rama. Aunque las especificaciones de objetos del control de versiones se
describen en una sección posterior, sirva como adelanto que las especificaciones
de rama tienen la forma:

br:/nombre_de_rama[#especificación_de_etiqueta]

Para ver los ítems que necesitan ser mezclados desde la rama ‘/main/child1’ al
contenido actual del espacio de trabajo:

cm mergebranch br:/main/child1

El comando ‘mergebranch’ con una especificación de rama únicamente muestra

los ítems que necesitan merge. Para llevar a cabo efectivamente la operación de
merge, hay que proporcionar el modificador ‘--merge’

cm mb --merge br:/main/child1

La operación de merge deja todos los elementos que ha mezclado desprotegidos,

para que puedan ser revisados y es el usuario el que debe protegerlos
explícitamente una vez decide que todo está correcto. Este comando hace un
checkin de todos los ítems desprotegidos como en el ejemplo presentado en la
sección de uncheckout:

cm fco –format={4} | cm ci –

Cherry Picking
El cherry picking es una forma diferente de ver el merge. Hasta ahora cuando
hablábamos de hacer un merge, hablábamos de mezclar el contenido de las
revisiones que conformaban el origen del merge con el contenido del espacio de
trabajo. Al hablar de cherry picking esto cambia.
El cherry picking es un merge, mediante el cual, un cambio/s en el contenido de
un elemento (delta/s), que ha sido introducido por una revisión, es aplicado en
el espacio de trabajo. En este caso no se hace el merge del contenido del
elemento en el origen, sino de los cambios que este ha incorporado en esa
revisión respecto a su revisión anterior.
En el siguiente ejemplo podrá verse más claramente la diferencia entre ambos.
Se tiene un fichero, en el que se ha añadido un método como parte de una
nueva funcionalidad que se está desarrollando. Más tarde en ese mismo fichero
se modifica uno de los métodos existentes para corregir un error que se ha
detectado. Si se hace un merge de este fichero como resultado se incorporará la
corrección en el método, pero también se incorporará el nuevo método que se
había desarrollado. En cambio si hace un cherry picking solamente se
incorporará la corrección en el método, pero no la nueva funcionalidad que se
había incorporado.
Es importante señalar que para que una modificación en un elemento sea
incorporada mediante el cherry picking toda ella debe de haberse introducido

43
 Manual de Usuario

mediante un solo cambio (una única operación de proteger) y no mediante

cambios sucesivos. Si se ha definido una función en un cambio, luego se han ido
haciendo cambios sucesivos para completar su funcionalidad y al final en un
último cambio se añade el comentario explicando la función. Al hacerse un
cherry picking del ultimo cambio sólo se incorporaría el cometario de la función,
pero ni la funcionalidad de la función ni la definición de la misma se
incorporarían al haberse realizado en cambios anteriores.

Para que un cambio pueda ser incorporado en el espacio de trabajo, sin

problemas, mediante la operación de cherry picking es necesario que la
versión sobre la que se realizo dicho cambio y la versión sobre la que se
desea aplicar sean similares. Si estas dos versiones son parecidas, o al menos
en la región o regiones de los cambios, el merge será automático, ya que los
cambios continúan siendo aplicables. Si por el contrario estas dos versiones
son completamente diferentes no habrá manera de identificar donde debe ir el
cambio, si es que continúa siendo aplicable en el nuevo contexto, y tendrá
que ser el usuario mediante la herramienta de merge el encargado de
aplicarlo.

El uso del cherry picking está más orientado al trabajo con conjuntos de cambios
o changesets dentro de una misma rama que al trabajo mediante rama por
tarea. En el caso de trabajar empleando una rama para cada cambio esta
operación pierde su sentido, porque todo cambio que se quisiese incorporar
estaría en una rama de forma aislada, por lo que puede ser incorporado sin
problemas mediante un merge de esa rama.
Tal y como se ha comentado antes el cherry picking tiene sentido cuando se
aplica a un cambio. Para realizar este cambio puede que sólo haya sido
necesario modificar un elemento o que se hayan modificados múltiples
elementos conjuntamente a través de un changeset. Por ello como orígenes
para el cherry picking se soportan:
• Desde una revisión. Si lo que se quiere es incorporar un cambio en un
único que elemento que ha sido realizado por una revisión, por lo que
haremos un cherry picking de dicha revisión.
• Desde un cahngeset. A diferencia del caso anterior, donde el cambio
afectaba a un único elemento suele suceder que para realizar un cambio
sea necesario modificar más de un elemento. Por ejemplo si se modifica
los parámetros de un a función es necesario modificar tanto el fichero
donde se define como todos los ficheros que contienen una llamada a esa
función. Si todos los elementos modificados para realizar ese cambio son
protegidos a la vez, están en un mismo changeset, podemos usar este
changeset para referirnos al cambio. Por ello para poder incorporar ese
cambio bastaría con hacer el cherry picking del changeset en el que se
hizo.
Aunque hemos estado hablando de cherry picking y no de merge, el cherry
picking no deja de ser un caso particular de merge.
Para poder realizar un cherry picking desde la línea de comandos se emplearía el
comando de merge con el modificador --cherrypicking, de está manera le
indicamos que el merge que ha de realizar es de este tipo. Por ejemplo el
comando para realizar un cherry picking de un changeset 50 quedaría de la
siguiente manera:

cm merge cs:50 --cherrypicking –merge

44
 Manual de Usuario

La Figura 48 muestra un proceso de merge normal, en el que todas las revisions

de la rama 001 se integran en la revisión 2 de la rama /main, pero en el caso de
la integración por Cherry pick, como muestra la Figura 49, solo se integra la
revisión que nos interesa, en este caso es la revisión 4 de la rama 001 la que se
integra en la rama /main, pero el usuario puede seleccionar que revisión o
revisiones le interesa en cada momento.

Rama /main
0

1
rama001

2 merge

Figura 48: Operación de merge Figura 49: Cherry-pick

Cherry Picking desde rama

Un caso particular de cherry picking es aquél que se realiza entre ramas. Como
antes comentamos, tendría poco sentido aplicar un cherry picking cuando se
trabaja en rama por tarea, pues normalmente se desea incorporar todos los
cambios introducidos en las ramas.
El caso del cherry picking desde rama es un poco especial, ya que cambia la idea
de “coger los cambios introducidos por el último changeset o la última revisión” a
“coger los cambios introducidos por la última rama”.
Supongamos el siguiente caso:

Figura 50: Cherry-pick desde rama

45
 Manual de Usuario

En el cual tenemos una rama principal de la que parte una rama de Fix a partir
de una etiqueta y de ésta parte una rama que implementa una tarea
determinada (task001).
Si a continuación realizáramos un merge normal de la rama task001 a la rama
principal, nos traeríamos todos los cambios introducidos por la rama de la tarea
y también todos los cambios introducidos por la rama de Fix.
En el caso de aplicar un cherry picking desde task001 a la rama principal,
solamente incorporaríamos los cambios introducidos por dicha rama task001,
desechando los cambios introducidos por la rama de Fix. El concepto es similar,
pero adaptado a la circunstancia especial de las ramas.
Para realizar esta operación en Plastic, ejecute un comando como el siguiente:

cm merge <branch_from> --cherrypicking –merge

Donde <branch_from> es la rama desde la que se desea realizar el cherry pick.

Desde la GUI, haga clic derecho sobre la rama desde la que desea realizar la
operación y seleccione la opción ‘Cherry pick desde esta rama’.

Merge de un intervalo de cambios

Antes cuando se ha hablado del cherry picking se ha explicado que este permite
incorporar un cambio en el espacio de trabajo. Pero tal, y como veíamos
mientras hablábamos del cherry picking pueden darse casos en los que una
modificación no se haya realizado mediante un único cambio sino mediante
cambios sucesivos. En estas ocasiones lo que nos interesa no es incorporar el
último de esos cambios, sino todos ellos.
El merge de un intervalo lo que permite es justamente eso, incorporar todos los
cambios existentes entre dos revisiones dadas. En este caso lo que estamos
haciendo es el merge de una revisión, pero teniendo en cuenta sólo aquello que
ha modificado desde una revisión dada.
Al igual que sucedía con el cherry picking, la incorporación de los cambios
realizados entre dos revisiones en el espacio de trabajo es otro caso particular
de merge, en realidad es una generalización del cherry picking.
Por ejemplo si se tiene una rama br:/main/fix y se quiere incorporar los cambios
realizados en el fichero “test” desde la revisión 5 a la 15, el comando de merge
quedaría de la siguiente manera:

cm merge rev:test#br:/main/fix#15 --
ancestor=rev:test#br:/main/fix#5 --merge

También en este caso si estamos usando un patrón de desarrollo de rama por

tarea, este tipo de merge pierde su utilidad. Para ver más información sobre el
uso de los diferentes patrones para la creación de ramas puede consultar el sitio
web de Códice: (www.codicesoftware.com).

3.11. Crear una etiqueta

Desde la interfaz gráfica 
Desde el menú de etiqueta: Crear Nueva Etiqueta.

46
 Manual de Usuario

Figura 51: Creación de una nueva etiqueta

Desde la línea de comandos 
Para crear una etiqueta se emplea el comando mklabel:

cm mklabel rel1.0

3.12. Aplicar una etiqueta

Desde la línea de comandos 
Aplicar una etiqueta implica indicar la etiqueta y la revisión a la que aplicarla.
Para aplicar la etiqueta ‘rel1.0’ a la revisión que se encuentra actualmente en el
espacio de trabajo del ítem ‘hello.cpp’ se emplea este comando:

cm label lb:rel1.0 hello.cpp

‘lb:rel1.0’ es la especificación de la etiqueta. Una sección posterior contiene la

referencia de todas las especificaciones de objeto que se pueden suministrar al
control de versiones.
Es normal aplicar una etiqueta a más de un ítem. El comando label admite el
modificador –R para hacerlo recursivo. Este comando etiqueta todos los ítems
que encuentran por debajo del directorio actual (sin incluir el propio
directorio .) con la etiqueta ‘rel1.0’

cm label lb:rel1.0 –R *

Es posible, asimismo, aplicar una etiqueta a una revisión específica,

suministrando una especificación de revisión:

47
 Manual de Usuario

cm label lb:rel1.0 hello.cpp#br:/main/child1#4

Que aplicará la etiqueta ‘rel1.0’ a la revisión 4 del elemento ‘hello.cpp’ en la

rama ‘/main/child1’ .

Desde la interfaz gráfica 

Figura 52: Aplicar etiqueta al contenido del espacio de tabajo

3.13. Poner código existente bajo el control de versiones

Plastic SCM sólo puede controlar los ficheros y directorios que se encuentran en
el espacio de trabajo, por lo que el paso previo para poner algo bajo el control
de versiones consiste en tenerlo dentro de un espacio de trabajo. Lo normal es
copiar los ficheros y directorios que componen el proyecto que se va a poner
bajo control de versiones al directorio del espacio de trabajo. Es posible añadir el
proyecto desde la interfaz gráfica, desde la línea de comandos, y desde las
integraciones con los entornos de desarrollo.

Desde la interfaz gráfica 
1. En la raíz del espacio de trabajo, botón derecho, opción de menú “Añadir
recursivamente”.
2. Botón “Desprot.” en la barra de herramientas, o menú “Ver / Mostrar
desprotecciones”.
3. Seleccionar todos los ítems con Ctrl-A
4. Botón “Checkin” en la barra de herramientas

48
 Manual de Usuario

Desde la línea de comandos 

cm add –R *
cm ci –R *

49
 Manual de Usuario

4. Empezando un proyecto

Plastic SCM ha sido diseñado para permitir una puesta en marcha rápida y
sencilla. Esta sección mostrará los pasos necesarios para empezar a poner un
proyecto bajo el control de versiones tanto desde la interfaz gráfica como desde
la línea de comandos.
Se mostrarán únicamente los pasos necesarios para completar las operaciones.
La mayoría de las operaciones ya han sido descritas con detalle en las secciones
anteriores.
Se asume que el usuario ha completado la instalación y configurado
correctamente el modo de autentificación en su cliente.

4.1. Creando un repositorio

Un repositorio denominado ‘default’ se crea durante el primer arranque del
servidor. Usando ese repositorio los usuarios pueden empezar a trabajar más
fácilmente, porque sólo necesitarán crear un espacio de trabajo, aquí se creará
uno nuevo y es el que se usará en el resto del ejemplo.

Desde la interfaz gráfica 
1. En el menú Repositorios / Crear nuevo repositorio
2. Introducir un nombre descriptivo y el servidor en el que se creará.

50
 Manual de Usuario

Figura 53: Diálogo de creación de repositorio

Desde la línea de comandos 

cm mkrep servername:8084 project3

4.2. Creación de un espacio de trabajo

La primera vez que un desarrollador arranca la herramienta GUI, si no se detecta
ningún espacio de trabajo, aparecerá un diálogo de creación, como muestra la
Figura 54. Por defecto, los espacios de trabajo apuntan al repositorio default y a
la rama main. Se podrá cambiar dependiendo de la estrategia de branching
utilizada.

Desde la interfaz gráfica 
1. En el menú Workpaces / Crear nuevo workspace
2. Introducir un nombre descriptivo, la ruta y el servidor en el que se creará

51
 Manual de Usuario

Figura 54: Creando un espacio de trabajo

Desde la línea de comandos 

cm mkwk dave_view c:\projects\view1

4.3. Poner código existente bajo el control de versiones

En el espacio de trabajo recién creado (c:\projects\view1\), copiar los ficheros y
directorios que componen el proyecto que se va a poner bajo control de
versiones. Es posible añadir el proyecto desde la interfaz gráfica, desde la línea
de comandos, y desde las integraciones con los entornos de desarrollo.

Desde la interfaz gráfica 

1. En la raíz del espacio de trabajo, botón derecho, opción de menú “Añadir

recursivamente”.
2. Botón “Desprot.” en la barra de herramientas, o menú “Ver / Mostrar
desprotecciones”.
3. Seleccionar todos los ítems con Ctrl-A
4. Botón “Checkin” en la barra de herramientas

Desde la línea de comandos 

cm add –R *
cm ci –R *

Desde la integración con Visual Studio 
Una vez el proyecto ha sido copiado en el espacio de trabajo, y está abierto en
Visual Studio:
3. Seleccionar la solución en el Explorador de Soluciones

52
 Manual de Usuario

4. Botón derecho, opción de menú “Agregar Solución al control de código

fuente”

Figura 55: Agregar la solución al control de código fuente

La integración con Visual Studio se encarga de proteger automáticamente los
ítems tras añadirlos a Plastic SCM. Cuando los ítems se encuentran bajo el
control de código fuente, aparece un candado a su lado indicando que su estado
es ‘protegido’.

Figura 56: Ítems en estado protegido

Los proyectos web, en especial con Visual Studio 2005, tienen un
comportamiento ligeramente distinto. Puede encontrar más información sobre el
trabajo con proyectos web en Visual Studio en el sitio web de Códice
(www.codicesoftware.com) en la sección de Soporte.

Desde la integración con Eclipse 
Se abrirá el proyecto en Eclipse de la manera habitual. Para añadir el proyecto
por primera vez a Plastic SCM, seleccionar el directorio de proyecto desde el

53
 Manual de Usuario

explorador de paquetes o desde el navegador, botón derecho, menú Team,

opción ‘Share Project’.

Figura 57: Añadir el proyecto a Plastic SCM

Eclipse pregunta qué control de versiones debe utilizar. Al seleccionar Plastic
SCM, hay que indicar al Plugin dónde puede encontrar el ejecutable ‘cm.exe’.
Normalmente se encontrará en el directorio ‘Archivos de programa\Plastic
SCM\client’, salvo que se haya especificado otra ubicación en la instalación.
De esta manera se crea el enlace entre el proyecto y Plastic SCM. El siguiente
paso es añadir los ítems propiamente. Se puede añadir todo el proyecto o sólo
una parte del mismo, si bien lo normal es añadirlo entero. Para ello, con el
directorio de proyecto todavía seleccionado, botón derecho, menú Team, opción
‘Add to Plastic SCM recursively’. Una vez añadidos, los ítems permanecen
desprotegidos, como denota el tick gris que aparece al lado de cada uno de ellos.

Figura 58: Elementos desprotegidos en Plastic SCM

Para completar la importación inicial, es necesario protegerlos. Con el directorio
de proyecto seleccionado, botón derecho, menú Team, opción ‘Check in
recursively’ los protegerá, y el tick gris cambia a un pequeño cilindro naranja,
indicando que están protegidos.

54
 Manual de Usuario

Figura 59: Protección recursiva

Ahora el proyecto está listo para ser usado por varios desarrolladores.

4.4. Empezando a trabajar: Obtener

Una vez que el código ha sido importado dentro del repositorio, el resto de los
desarrolladores puede obtener una copia local en su propio espacio de trabajo:
Este proceso se denomina hacer un update.

Desde la interfaz gráfica 
1. Botón “Obtener” en la barra de herramientas.

Figura 60. Realizando una operación de Obtener

Desde la línea de comandos 

cm update .

55
 Manual de Usuario

4.5. Desprotegiendo ítems para trabajar con ellos

Para realizar un cambio a cualquier ítem bajo el control de versiones hay que
desprotegerlo.

Desde la interfaz gráfica 
1. Seleccionar el ítem que se quiere desproteger.
2. Botón derecho, en el menú, opción “Desproteger”, o bien botón
“Desproteger” en la barra de herramientas.

Desde la línea de comandos 
Para desproteger un ítem cualquiera:

cm co nombre_del_ítem nombre_de_otro_ítem

Para desproteger de manera recursiva un directorio y todos sus contenidos:

cm co –R directorio/*

Desproteger todos los ítems leídos desde la entrada estándar:

cm co -

Desde la integración con Visual Studio 
La integración con Visual Studio desprotege de manera automática los ítems en
el momento en que empiezan a modificarse. Cuando un ítem está desprotegido,
el candado al lado de ese ítem en el Explorador de Soluciones se reemplaza por
una marca de edición.

Figura 61: Detalle de elemento desprotegido en Visual Studio

Visual Studio puede configurarse para preguntar antes de desproteger un ítem,
desde el menú de opciones. Cuando esta preferencia esta activa, al desproteger
un ítem aparece este diálogo:

56
 Manual de Usuario

Figura 62: Diálogo de desprotección de Visual Studio 2003

Desde la integración con Eclipse 
En Eclipse los ítems son desprotegidos de forma automática cuando se empiezan
a modificar en el editor. Es posible desproteger varios ítems seleccionándolos en
el explorador de paquetes o en el navegador, y botón derecho, menú Team,
opción ‘Checkout’.

4.6. Mostrando las protecciones pendientes

Desde la interfaz gráfica 

Figura 63. Listar las revisiones desprotegidas

Desde la línea de comandos 

cm findcheckouts
cm fco

57
 Manual de Usuario

Desde la integración con Visual Studio 
Visual Studio permite mostrar los ítems que necesitan ser protegidos haciendo
click con el botón derecho en un ítem desprotegido y seleccionando la opción
‘Mostrar protecciones pendientes’.

58
 Manual de Usuario

5. Selectores en profundidad

Los selectores son la pieza central de los espacios de trabajo porque contienen el
conjunto de reglas que determinan sus contenidos. Configurando el selector un
usuario podrá indicar con precisión y comodidad los ítems sobre los que va a
trabajar. Este punto describe cómo crear y configurar selectores.

5.1. Aspecto de un selector

Un selector es una especificación de qué revisiones de qué ítems serán
descargados al espacio de trabajo en el disco del usuario. Indica también en qué
rama se crearán las desprotecciones (checkouts), es decir, las nuevas revisiones.
Un selector muy común será el que muestra la Figura 64. En primer lugar el
selector indica sobre qué repositorio se trabajará, mediante la regla de selección
de repositorio.

Figura 64. Apariencia del selector por defecto

Una vez que se selecciona un repositorio el siguiente paso es decir exactamente
qué descargar. En el ejemplo la regla de selección de path indica que se
descargará todo aquello por debajo del directorio raíz.
Un selector siempre debe indicar una regla para descargar el directorio
raíz, de otro modo Plastic lanzará un error. Para obtener los ficheros y
directorios desde el repositorio hasta el espacio de trabajo, Plastic necesita
resolver los paths desde el directorio raíz hacia abajo, según las reglas del

59
 Manual de Usuario

selector, y por eso es necesario que todos los ítems puedan encontrar una regla
adecuada.
Dentro de la regla de selección de path hay otra especificación que indica la
rama de origen y la rama sobre la que hacer check outs.

5.2. Definición del selector

La Figura 65 muestra la definición completa del selector. Hay muchas
posibilidades disponibles para poder indicar exactamente qué debe descargarse
al espacio de trabajo.
Un selector consiste en una o varias reglas de carga de repositorio, cada una de
las cuales define uno o más paths que deberán procesarse, y en qué lugar
estarán las revisiones de los ítems (branches, etiquetas, changesets o números
de revisión).

60
 Manual de Usuario

Figura 65. Definición de la gramática del selector

5.3. Reglas de path

Las reglas de path son las que definen exactamente qué se va a descargar a un
path determinado. Se ejecutan en orden, lo que significa que si una regla es
capaz de cargar un ítem, las reglas siguientes no serán usadas.

61
 Manual de Usuario

El siguiente ejemplo muestra cómo funcionan las reglas de path:

repository "codice"
path "/01nerva/doc"
br "/main/SCM0841" co "/main/SCM0841"
path "/"
br "/main"

El selector indica que se cargarán las revisiones de los ítems dentro del path
/01nerva/doc que están en la rama /main/SCM0841 y los checkouts que se
produzcan irán a la misma rama. Todo lo demás, incluyendo el directorio raíz, se
descargará desde la rama main.
Pero, ¿qué ocurriría con el siguiente selector?:

repository "codice"
path "/"
br "/main"
path "/01nerva/doc"
br "/main/SCM0841" co "/main/SCM0841"

En el segundo selector las reglas de path han sido intercambiadas. Ahora la regla
del path “/” será evaluada primero, y como todos los ítems pueden ser resueltos
con esa regla, la segunda no se usará nunca.

5.4. La opción norecursive de la regla path

La opción norecursive significa que la regla se aplicará al directorio, pero no a los
ítems que contiene.
Si se dispone de una estructura como la ilustrada en la Figura 66 y sólo se
quiere trabajar con los contenidos del directorio /01nerva/doc, no es necesario
descargar toda la estructura de directorios.

62
 Manual de Usuario

Figura 66. Estructura de repositorio de ejemplo

Para descargar únicamente el directorio deseado se usará un selector como:

repository "codice"
path "/01nerva/doc"
lb "BL034"
path "/01nerva" norecursive
lb "BL034"
path "/" norecursive
br "/main"

El selector sólo descargará las revisiones de los ítems dentro del path requerido,
cogiendo las revisiones etiquetadas con BL034.

5.5. Comodines en la regla de selección de path

En ciertas situaciones sólo es necesario descargar ciertos elementos al espacio
de trabajo. Para descargar sólo los ficheros .doc en el ejemplo anterior se usará
un selector como:

63
 Manual de Usuario

repository "codice"
path "/01nerva/doc/*.doc"
lb "BL034"
path "/01nerva/doc" norecursive
lb "BL034"
path "/01nerva" norecursive
lb "BL034"
path "/" norecursive
br "/main"

5.6. Obteniendo una revisión específica de un ítem

Si necesita descargar una revisión específica de un ítem concreto, la opción
revno de la regla de branch del selector será útil. Revno puede ser un número o
los nombres especiales LAST y FIRST. LAST indica la última revisión en la rama y
FIRST la primera.
Volviendo al ejemplo anterior se verá un selector capaz de descargar una
revisión concreta el fichero /01nerva/doc/manual.doc:

repository "codice"
path "/01nerva/doc/manual.doc"
br "/main" revno "5"
path "/01nerva/doc"
lb "BL034"
path "/01nerva" norecursive
lb "BL034"
path "/" norecursive
br "/main"

64
 Manual de Usuario

6. Especificaciones de objetos

En Plastic SCM todos los objetos pueden ser referenciados mediante

especificaciones de objetos. Los especificadores no son muy comunes cuando se
usa la herramienta gráfica, pero es interesante conocer cómo el sistema
referencia los objetos.

6.1. Especificaciones de revisión

Para referenciar una revisión específica de un ítem, se puede usar uno de los
siguientes formatos:

path#branch name#revision number

path#label name

Por ejemplo, es posible referenciar la revisión 23 del fichero /src/main.java en la

rama main con la siguiente sintaxis:

/src/main.java#br:/main#23

Otra posibilidad sería acceder a una revisión etiquetada:

/src/main.java#lb:RELEASE001

65
 Manual de Usuario

6.2. Especificaciones de rama

Los especificadores de rama se usan durante el merge o al fijar selectores y
tienen la sintaxis siguiente:

br:branch_name

Ejemplos:

br:/main

br:/main/release00

6.3. Especificaciones de ítem

Las especificaciones de ítem serán:

item:path

Ejemplo:

item:/src/hello.java

6.4. Especificaciones de etiqueta

Una especificación de etiqueta tendrá el siguiente formato:

lb:label_name

Ejemplo:

lb:LABEL001

6.5. Especificaciones de repositorio

La especificación de un repositorio tendrá el formato:

rep:repository_name@repository_server

Ejemplo:

rep:myrep@REPSERVER:8084

66
 Manual de Usuario

6.6. Especificaciones de espacio de trabajo

Para referenciar un workspace la sintaxis será:

wk:workspace_name@client_machine

Ejemplo:

wk:integrator_wk@releaseserver

6.7. Especificaciones de servidor de repositorios

La sintaxis de una especificación de servidor de repositorios será:

repserver:servername:portnumber

Ejemplo:

repserver:mainRepServer:8084

6.8. Especificaciones de servidor de workspaces

La especificación de un servidor de workspaces será:

wkserver:servername:portnumber

Ejemplo:

wkserver:WorkspaceServer:8084

67
 Manual de Usuario

7. Interfaz gráfica

La interfaz gráfica, o GUI de manera abreviada, es la principal herramienta para

controlar el entorno de Plastic SCM. A través de ella es posible realizar la
mayoría de las operaciones con el control de versiones, a excepción de unos
pocos comandos de administración.

7.1. Ventana principal

La interfaz gráfica siempre actuará sobre un espacio de trabajo determinado,
que podrá ser seleccionado a gusto del usuario. Por eso, la primera vez que se
ejecuta mostrará un cuadro de diálogo pidiendo información sobre el espacio de
trabajo a utilizar. En caso de que no exista ninguno, el cuadro avisará de este
hecho, y permitirá crear uno nuevo.

Figura 67: Selección de un espacio de trabajo

68
 Manual de Usuario

Cuando se especifica un servidor al que conectar y se pulsa “Listar espacios de

trabajo” (Retrieve Workspaces en la versión inglesa), Plastic SCM mostrará la
lista de los espacios de trabajo asociados a la máquina desde la que se esta
ejecutando la interfaz gráfica. Si no se existe ninguno, se mostrará un aviso
indicando esta situación. Es posible crear un nuevo espacio de trabajo a través
del botón Nuevo… en la parte inferior del diálogo. Una vez creado, la interfaz
gráfica mostrará su ventana principal. La Figura 68 muestra los componentes de
esta:

Figura 68. Ventana principal de GUI

En la ventana principal aparecen las vistas que se van a explicar en la siguiente
sección, como se muestra en la figura se pueden abrir de manera simultánea y
el usuario puede ir de una a otra moviéndolas desde la barra de la izquierda.
La GUI muestra siempre los espacios de trabajo disponibles y el que está activo
en cada momento en la esquina superior izquierda, además del repositorio, rama
y etiqueta en los que el usuario está trabajando en cada momento (en la esquina
superior derecha).
Significado de los iconos que se muestran en la GUI:

Item controlado
Item desprotegido
Item existente en Plastic pero no en el espacio de trabajo
El item no está en disco
Item existente en Plastic y desprotegido pero no existe en el espacio de
trabajo

69
 Manual de Usuario

7.2. Sistema de vistas

The main window is capable of displaying different views of a Plastic repository.
The available views are:
La parte derecha de la ventana principal, es capaz de mostrar las diferentes
vistas de un repositorio de Plastic. Las vistas disponibles son las siguientes:
• Vista de ítems: Muestra los ítems del espacio de trabajo actual.
• Vista de ramas: Muestra un listado de ramas.
• Explorador de ramas: Muestra el explorador de ramas del repositorio
seleccionado.
• Changesets: Muestra los changesets del repositorio seleccionado.
• Vista de etiquetas: Muestra un listado de etiquetas.
• Vista de ítems desprotegidos: Muestra las desprotecciones que tiene el
usuario en su espacio de trabajo actual.
• Vista de todas las desprotecciones: Muestra las desprotecciones de
todos los usuarios que hay actualmente en el repositorio.
• Vista de espacios de trabajo: Muestra un listado de todos los
workspaces existentes en el servidor de workspaces.
• Vista de repositorios: Obtiene la lista de los repositorios disponibles.

7.3. Selección del espacio de trabajo

Un usuario puede tener tantos espacios de trabajo como necesite. Cada uno de
ellos se puede utilizar para señalar varias versiones diferentes del proyecto o
para realizar diversas tareas.
Utilizando la herramienta gráfica el usuario puede cambiar de un espacio de
trabajo a otro en cualquier momento desde la esquina superior izquierda de la
herramienta como muestra la Figura 69.

Figura 69: Selección del espacio de trabajo

El espacio de trabajo activo aparecerá en letras naranjas como es el caso del
espacio de trabajo “tmp_wk” en la figura, que además se indica como
“Workspace activo” más abajo.

7.4. Modificar el selector

Para cambiar el selector del espacio de trabajo actual, el usuario tendrá que
acceder al menú Workspace/Establecer Selector. La Figura 70 muestra el diálogo
que permite editar el selector.

70
 Manual de Usuario

Figura 70: Diálogo de edición del selector

7.5. Menús contextuales

Todos los objetos en la GUI tienen un menú contextual asociado. Se describirán
a continuación cada uno de ellos.

Menú de ítem  
Añadir Añade el item a la solución
Añadir Añade el item a la solución
(recursivo) recursivamente
Obtener Actualiza el ítem seleccionado
Obtener todo Actualiza el ítem seleccionado,
forzando su descarga
Abrir Abre la revisión seleccionada
con la aplicación asociada
Abrir con Muestra un diálogo para
escoger una aplicación con la
que abrir el fichero
Diferencias Abre el diálogo de diferencias
Proteger Protege las revisiones
seleccionadas
Proteger Protege las revisiones
(recursivo) seleccionadas recursivamente

71
 Manual de Usuario

Desproteger Desprotege los ítems

seleccionados
Desproteger Desprotege los items
(recursivo) seleccionados recursivamente
Deshacer Deshace la desprotección
desprotección
Renombrar Renombra el ítem
Borrar Elimina la revisión de su
directorio padre
Cambiar tipo Cambia el tipo del ítem de
de revisión binario a texto o viceversa
Nuevo Crea un nuevo fichero o
directorio
Ver Historial Muestra la historia del ítem
de revisiones
Ver árbol de Muestra un árbol con todas las
revisiones revisiones del ítem
seleccionado
Permisos Muestra los diversos permisos
Localizar en Localiza el elemento en el
árbol explorador de workspace
Ver items Muestra los items privados
privados
Tabla 1: El menú de ítem

Menú de rama  
Ver revisiones Muestra las revisiones de la
en la rama rama seleccionada
Crear rama hija Crea una rama hija de otra
dada
Merge desde Toma la rama seleccionada
esta rama como origen para un merge
Apuntar Cambia la configuración del
workspace a espacio de trabajo para que
esta rama apunte a la rama
seleccionada
Renombrar Renombra la rama

Borrar Borra la rama seleccionada

Comparar con Compara la rama

etiqueta seleccionada con una
etiqueta
Comparar Compara la rama
contenido de la seleccionada con su
rama contenido anterior
Comparar con Compara la rama
rama seleccionada con otra rama

72
 Manual de Usuario

Permisos Muestra los permisos de la

rama
Tabla 2: Menú de rama

Menú de etiqueta  
Mostrar Muestra las revisiones
revisiones que están etiquetadas
etiquetadas
Etiquetar Aplica la etiqueta
estado actual seleccionada al contenido
del espacio de trabajo
Renombrar Renombra la etiqueta
seleccionada
Borrar Borra la etiqueta

Comparar con Compara la etiqueta

etiqueta seleccionada con otra
Merge desde Toma la etiqueta
esta etiqueta seleccionada como
origen para un merge
Apuntar Cambia la configuración
workspace a del espacio de trabajo
esta etiqueta para que apunte a la
etiqueta seleccionada
Permisos Permisos de la etiqueta

Tabla 3: Menú de etiqueta

Menú de elementos privados  
Añadir Añade los elementos
seleccionados al control de
versiones
Añadir Añade recursivamente un
(recursivo) directorio
Obtener Actualiza el ítem
seleccionado
Obtener todo Actualiza el ítem
seleccionado forzando su
descarga
Abrir Abre el fichero
Abrir con Muestra un diálogo para
escoger la aplicación con la
que abrir los ficheros
seleccionados
Diferencias Muestra el diálogo de
diferencias
Proteger Protege la revisión
seleccionada

73
 Manual de Usuario

Proteger Protege la revisión

(recursivo) seleccionada recursivamente
Desproteger Desprotege la revisión
seleccionada
Desproteger Desprotege la revisión
(recursivo) seleccionada recursivamente
Deshacer Deshace la desprotección
desprotección
Renombrar Renombra un fichero o
directorio
Borrar Borra los ítems seleccionados
Cambiar tipo Cambia el tipo del ítem de
de revisión binario a texto o viceversa
Nuevo Crea un nuevo fichero o
directorio
Ver historial de Muestra la historia del ítem
revisiones
Ver árbol de Muestra un árbol con todas
revisiones las revisiones del ítem
seleccionado
Permisos Muestra los diversos
permisos
Ver items Muestras los ítems que han
cambiados cambiado
Ver items Muestra los ítems privados
privados
Tabla 4: Menú de elementos privados

Menú contextual de revisiones 
Se muestra desde la vista de historia.
Abrir Abrir las revisiones
seleccionadas
Abrir con Muestra un diálogo para
elegir la aplicación con la
que abrir las revisiones
Ver contenido Muestra el contenido del
del changeset changeset seleccionado
Diferencias Lanza el diálogo de
diferencias
Árbol de Muestra el árbol de
revisiones versiones
Guardar revisión Guarda la revisión
como seleccionada con el nombre
que se le dé
Volver a esta Vuelve a la revisión
revisión seleccionada

74
 Manual de Usuario

Merge desde Toma la revisión

esta revisión seleccionada como origen
de una operación de merge
Merge desde Toma el intervalo de
este intervalo de revisiones seleccionadas
revisiones como origen de una
operación de merge
Cherry pick Toma la revisión
desde esta seleccionada como origen
revisión de una operación de
cherrypick
Permisos Muestra los permisos de la
revisión
Tabla 5: Menú de revisiones

7.6. Diálogo de diferencias

Plastic SCM proporciona su propia herramienta de diferencias. Desde la
herramienta gráfica es posible mostrar las diferencias tanto de distintas
revisiones de ficheros como de directorios. Se pueden mostrar diferencias de
ficheros privados y controlados.
El diálogo de diferencias se muestra en la Figura 71.

Ítem o elemento privado

Explorador de ítems

Selector de revisiones (no activado Explorador de ramas

con privados)

Especificación de la revisión
Explorador de revisiones

Figura 71: Diálogo de diferencias

Para poder mostrar diferencias se deben seleccionar dos revisiones. Para
comparar ficheros privados, dos paths.
Para comparar ficheros controlados por el SCM están disponibles las siguientes
opciones:

75
 Manual de Usuario

• Revisión en el workspace: se tomará la revisión cargada en el espacio de

trabajo.
• Última revisión en una rama: se selecciona una rama y se toma la última
revisión del ítem en esa rama.
• Otro: se puede escoger cualquier revisión en el diálogo de revisiones.

7.7. Herramienta de diferencias de código

La herramienta de diferencias puede ser invocada desde la herramienta gráfica
para mostrar las diferencias entre revisiones de ficheros y de directorios.
Pueden compararse dos revisiones de un mismo directorio, y la herramienta
mostrará qué ítems han cambiado como muestra la Figura 72.

Figura 72: Diferencias de directorios mostrando un fichero añadido

La herramienta de diferencias también puede usarse para código fuente. La
Figura 73 muestra la herramienta resaltando las diferencias entre diferentes
revisiones de un mismo fichero.

76
 Manual de Usuario

Figura 73: Diferencia de código con sintaxis resaltada

7.8. Herramienta de diferencias de imágenes

Es posible comparar imágenes mediante la herramienta de diferencias de
imágenes de Plastic SCM.
La herramienta ha sido específicamente diseñada para ayudar a los diseñadores
gráficos a controlar las modificaciones realizadas sobre contenidos gráficos.
La herramienta puede mostrar las diferencias de dos modos: por un lado puede
mostrar las imágenes una al lado de la otra, de modo que se puedan ver los
cambios con facilidad, como muestra la Figura 74.

Figura 74: Diferencia de imágenes mostrando gráficos en paralelo

La segunda forma de mostrar las diferencias es superponiendo ambas revisiones,
pudiendo el usuario manipular el factor de transparencia con el que se
combinan. Esta opción es útil para detectar cambios pequeños en imágenes que
varían poco.

77
 Manual de Usuario

Figura 75: Herramienta de diferencias gráficas mostrando imágenes

combinadas

7.9. El diálogo de merge

El diálogo de merge es el responsable de reconciliar los cambios entre las
diferentes revisiones modificadas en paralelo, ya sea trabajando sobre una
misma rama o sobre muchas ramas a la vez.
La Figura 76 muestra en detalle el diálogo de merge:
Rama origen

Explorador de ramas

Explorador de etiquetas

Ítems que necesitan merge

Contribuidores del merge

Tipo de conflicto

Merge de todos los ítems

Mostrar/Esconder Opciones

Buscar ítems que necesitan merge Merge de ítems seleccionados

Figura 76: El diálogo de merge

El primer paso será especificar la rama de origen, que es la rama que contiene
los cambios que se van a integrar con el contenido actual del workspace.
Una vez que el origen se ha especificado, el siguiente paso será encontrar qué
ítems necesitarán ser combinados. Para eso se usará el botón Buscar merges.

78
 Manual de Usuario

En ese momento se listarán los elementos de los que habrá que hacer el merge.
Los botones Merge de todos y merge servirán para lanzar el proceso. La Tabla 6
explica cada una de las opciones de merge disponibles.
Merge automático sólo si cambia un El merge será automático sólo si el
contribuidor fichero ha sido modificado en el origen
o en el destino, pero no en ambos
Merge automático sólo si cambia el Esta opción de merge es un poco más
origen restrictiva. El merge será automático
sólo si el contribuidor origen ha
cambiado.
Los usuarios pueden fijar esta opción
para comprobar los cambios realizados
sobre el destino.
Merge automático sólo si cambia el El merge será automático sólo si el
destino destino ha cambiado.
Mezclar cambios de ambos El merge será automático sólo si cada
contribuidores línea ha sido cambiada por un único
contribuidor o por ambos del mismo
modo.
Resolución automática de conflictos El sistema de merge intentará
combinar automáticamente los
cambios por parte de ambos
contribuidores, incluso realizados
sobre las mismas líneas, siempre que
sea posible.
Tabla 6. Opciones de merge

7.10. Herramienta de merge para ficheros de texto

Plastic SCM incluye una herramienta de merge propia. Su principal objetivo es
reconciliar los cambios en ficheros realizando lo que comúnmente se conoce
como un merge de tres vías.
La herramienta de merge también se puede invocar como una aplicación
independiente: mergetool.exe.
Cuando se lanza manualmente, la herramienta de merge mostrará (si no se
especifican opciones por línea de comandos), un diálogo como el de la Figura 77.

79
 Manual de Usuario

Figura 77: Diálogo de selección de ficheros de merge tool

Cuando sólo se especifican dos ficheros mergetool únicamente mostrará las
diferencias entre ambos, colocando los ficheros emparejados como en la figura
siguiente:

Figura 78: Herramienta de merge para ficheros de texto

Cuando se introducen tres ficheros, como ocurre cuando el merge es invocado

por la herramienta gráfica, se lanzará la herramienta de merge de tres vías.
La herramienta de merge mostrará cada uno de los contribuidores, así como el
resultado de la integración.
Como es una herramienta de merge de tres vías (three-way merge tool), se
mostrará también el antecesor común o fichero base desde el que partieron
ambos contribuidores.

80
 Manual de Usuario

Figura 79: La herramienta de merge

La herramienta proporciona flechas de navegación para moverse entre los
conflictos. Hay dos tipos de flechas: una para moverse por todos los conflictos
(automáticos y manuales) y otra sólo para navegar por los manuales (los que el
usuario debe examinar por no ser automáticos).
Los conflictos automáticos no necesitan, normalmente, que el usuario realice
ninguna acción sobre ellos. La herramienta es capaz de elegir los contribuidores
automáticamente.
Para resolver los conflictos manuales la herramienta siempre preguntará al
usuario. Por defecto propondrá los tres contribuidores, y el usuario será el
encargado de dejar sólo aquellos que sean correctos, o incluso modificar
manualmente el resultado.
Para seleccionar o eliminar un contribuidor bastará con hacer clic en la etiqueta
ubicada sobre cada contribuidor.

7.11. La herramienta de merge binario

Cuando se necesite hacer un merge de ficheros binarios que no sean imágenes,
la herramienta de merges binarios gestionará el proceso.
Los merges binarios son mucho más simples que los de ficheros de texto. Los
usuarios sólo tendrán que escoger uno de los participantes en el merge como
resultado de la operación, no se realizará mezcla de contenidos. La Figura 80
muestra la herramienta de merge binaria.

81
 Manual de Usuario

Figura 80: Herramienta de merges binarios

82
 Manual de Usuario

8. Gestionando proyectos con Plastic SCM

Disponer de un sistema SCM no es suficiente para poder gestionar

correctamente un proyecto. Será necesario también conocer cómo estructurar el
trabajo de desarrollo.
En este punto se introducirán diferentes métodos de trabajo, estrictamente
relacionados con diferentes patrones de branching.

8.1. Trabajando en la rama principal

Se trata de un patrón muy común, y es el que se emplea con sistemas de control
de versiones como Subversion, CVS o SourceSafe. Es muy sencillo de configurar,
pero tiene muchos inconvenientes.
La Figura 81 ilustra el proceso. Cada desarrollador trabaja en su propio espacio
de trabajo (workspace). Cada uno de ellos puede desproteger (check out) tantos
ficheros y directorios como necesite, pero cuando tenga que protegerlos (check
in) los cambios irán directamente a la rama br:/main. Los programadores, por
tanto, tendrán que ser muy cuidadosos con sus check outs.

Figura 81: Todos los cambios en la rama principal

83
 Manual de Usuario

Si un programador protege unos cambios (tanto ficheros como directorios) y otro

desarrollador actualiza inmediatamente su workspace, recibirá las modificaciones
recién subidas. Si había algo erróneo en el check in del primer programador, el
problema se propagará al trabajo del segundo.
El principal problema con este modelo es que no hay lugares intermedios en los
que almacenar los cambios antes de pasar a la línea principal. Por tanto los
check ins son menos frecuentes, dejando que el código pase mucho tiempo fuera
del control de versiones. Los desarrolladores no usan el SCM como una
herramienta para ayudarles en su trabajo diario, sólo para enviar trabajo
terminado.
Se desaconseja el uso de este modelo.

Cómo hacerlo con Plastic SCM 
Para usar este modelo los programadores tendrán que usar el siguiente selector:

repository "default"
path "/"
br "/main"
co "/main"

8.2. Rama por desarrollador

Usando este patrón los desarrolladores dispondrán de un mayor aislamiento. De
este modo podrán hacer tantas protecciones intermedias como necesiten, sin
comprometer la integridad de la rama principal. La Figura 82 muestra cómo
funciona el modelo.

Figura 82: Patrón de rama por desarrollador

El trabajo podrá ser dividido en tareas, controladas por un sistema de gestión de
tareas o defectos. Cada desarrollador implementará las tareas que se le asignen
en su propia rama.
Una vez que varias tareas hayan sido completadas y con una frecuencia que será
inversamente proporcional al número de desarrolladores, se creará una nueva
release, integrando todas las ramas en la línea principal. La integración podrá
ser realizada por cada desarrollador o por un integrador responsable del paso a
la línea principal.
Una vez que la integración (que se realizará mediante operaciones de merge
desde cada una de las ramas) haya sido completada se creará una nueva
baseline etiquetando los nuevos contenidos. Después cada desarrollador
realizará un rebase (un merge desde br:/main) a su rama para continuar
trabajando con los últimos contenidos.

84
 Manual de Usuario

Cómo hacerlo con Plastic SCM 
Para implementar este modo de trabajo cada desarrollador tendrá un selector
como el siguiente:

repository "default"
path "/"
br "/main/developerbranch"
co "/main/developerbranch"

Donde developerbranch será el nombre o identificador del desarrollador, según

la convención de nombres que se elija.
Para integrar el trabajo hacia main cada desarrollador, o el integrador, usará el
siguiente selector:

repository "default"
path "/"
br "/main"
co "/main"

8.3. Rama por tarea

Usando el patrón de rama por tarea se creará una nueva rama por cada una de
las tareas asignadas a un desarrollador.
Se trata del patrón que mayor aislamiento y control proporciona, pero requiere
que el SCM soporte un fuerte trabajo con ramas. Plastic SCM es capaz de
implementar el patrón sin ningún impacto en el rendimiento o integridad del
sistema, a diferencia de lo que ocurriría con otros SCMs.
Cada desarrollador trabajará en una rama, aislando su trabajo, y cambiará a una
nueva rama cada vez que complete una tarea.
El integrador creará nuevas releases y baselines con una frecuencia fija,
integrando las ramas de tarea que hayan sido terminadas y probadas.
El patrón de rama por tarea posibilita un máximo aislamiento entre
desarrolladores, y facilita mantener la estabilidad del producto en su línea
principal. Mejora la productividad de los programadores permitiendo que usen el
SCM para ayudarles en su trabajo diario.
La Figura 83 ilustra el patrón.

Figura 83: El patrón de rama por tarea

85
 Manual de Usuario

Cómo hacerlo con Plastic SCM 
Un posible selector para los desarrolladores será:

repository "default"
path "/"
br "/main/taskXXX" label “BL101”
co "/main/taskXXX"

Donde taskXXX será reemplazado por el número de tarea.

Existe un modo de simplificar el selector:

repository "default"
path "/"
branchpertask “/main/taskXXX” baseline “BL101”

El integrador trabajará en la rama principal con el siguiente selector:

repository "default"
path "/"
br "/main"
co "/main"

86
 Manual de Usuario

9. Visual Studio Plug In

El Plug In de Visual Studio permitirá a los usuarios trabajar con Plastic SCM
desde cualquier entorno de desarrollo compatible con el API SCC. El Plug-in es
totalmente compatible con Visual Studio 6, 2003 y 2005.
Se describirán las principales operaciones que permitirán trabajar con fluidez con
el sistema desde Visual Studio.

9.1. Añadir proyectos al control de código fuente

Esta operación se realiza cuando la solución con la que se quiere trabajar, existe
en disco, pero aún no está bajo el control de Plastic SCM.
Requisitos:
• Los archivos de proyecto deben estar ubicados dentro de un workspace.
• Debe estar instalado el plugin para Visual Studio de Plastic SCM.
Pasos a seguir:
• Abrir el proyecto/solución Visual Studio
• Pulsar con el botón derecho sobre la solución o el proyecto
• Seleccionar Agregar solución al control de código fuente

87
 Manual de Usuario

Figura 84: Añadir al control de versiones desde Visual Studio

• La solución quedará agregada a Plastic.

9.2. Abrir proyectos existentes en el control de código

fuente
Esta operación se realiza cuando la solución con la que se quieren trabajar ha
sido añadida previamente a Plastic SCM. En este caso, hay que informar a Plastic
de la ubicación de la solución.
Para ello se seguirán los siguientes pasos:
• Abrir la solución con Visual Studio
• Hacer click sobre Archivo / Control de código fuente / Cambiar control de
código fuente. Ver Figura 85.

Figura 85: Cambiar de control de código fuente en Visual Studio

• En el cuadro de diálogo de la Figura 86, seleccionar todos los
proyectos y soluciones que se deseen asociar con el control de código
fuente, y pulsar el botón de enlazar. Una vez enlazados, pulsar
Aceptar

88
 Manual de Usuario

Figura 86: Enlazar proyectos

9.3. Operaciones básicas

En el menú contextual de cada fichero de Visual Studio, hay una serie de
operaciones básicas relacionadas con el control de código fuente. Ver Figura 87 y
Figura 88.

Figura 87: Operaciones

sobre un fichero
protegido
Figura 88: Operaciones
sobre un fichero
desprotegido

• Desproteger ahora: Hace check out de los elementos seleccionados. Si

se trata de una solución o de un proyecto, se hará check out de todos
los archivos pertenecientes a esta solución o proyecto.
• Obtener última versión: Hace update del elemento seleccionado.
• Comparar versiones: Muestra diferencias entre la revisión del
workspace y la revisión del servidor.

89
 Manual de Usuario

• Proteger ahora: Hace check in de los elementos seleccionados.

• Mostrar protecciones pendientes: Muestra todos los elementos en
check out.
• Deshacer desprotección: Cancela la desprotección de los ítems
seleccionados, dejándolos como estaban antes de la desprotección.

9.4. Otras operaciones de control de código fuente

El resto de operaciones de control de código fuente pueden encontrarse en el
menú de Archivo / Control de código fuente, como muestra la Figura 89.

Figura 89: Operaciones SCM adicionales en Visual Studio

• Abrir desde el control de código fuente: Muestra una solución para abrir
una solución o proyecto desde el control de código fuente.
• Cambiar control de código fuente: Muestra el diálogo para enlazar y
desenlazar proyectos del control de código fuente, o trabajar
desconectado.
• Obtener la última versión: Hace una operación de update de los
elementos seleccionados.
• Obtener: Muestra un diálogo para hacer update.
• Desproteger: Desprotege los ítems seleccionados.
• Desproteger ahora: Desprotege los ítems seleccionados sin cuadro de
diálogo.
• Proteger: Protege los ítems seleccionados
• Deshacer desprotección: Deshace la desprotección de los elementos
seleccionados.
• Historial: Muestra un árbol de revisiones del ítem seleccionado.
• Excluir del control de código fuente: Quita los ficheros seleccionados del
control de código fuente.
• Compartir: No utilizado
• Comparar versiones: Muestra diferencias entre la versión actual del ítem
seleccionado y su inmediata predecesora.

90
 Manual de Usuario

• Propiedades de Plastic: Muestra una ventana de propiedades del Plugin.

• Agregar proyecto desde el control de código fuente: Equivalente a abrir
desde el control de código fuente
• Actualizar estado: Actualiza el estado de los elementos seleccionados,
suponiendo que hayan sido modificados desde fuera de Visual Studio.

9.5. Trabajar desconectado

Cuando por alguna razón no hay conexión de red y es necesario realizar cambios
en el proyecto, se puede utilizar la opción de trabajar desconectado. Se seguirán
los pasos que se describen a continuación.
En primer lugar se accederá a Archivo / Control de código fuente / Cambiar
control de código fuente, como muestra la Figura 90. Se pulsará el botón
desconectar.

Figura 90: Cambiar control de código fuente

El sistema es capaz de memorizar los check outs realizados por el usuario,
seleccionando Desproteger (sin conexión). Cuando esto ocurra se mostrará un
diálogo como el de la Figura 91.

Figura 91: Desprotección sin conexión

Cuando el plugin recupere la conexión, se envían al servidor los check outs
realizados fuera de línea, mostrando un mensaje como el de la Figura 92.

Figura 92: Protección tras recuperar la conexión

91
 Manual de Usuario

10. Eclipse Plug In

El Plugin de Eclipse permite a los usuarios trabajar con Plastic SCM desde el
entorno integrado de Eclipse, ofreciendo las operaciones más comunes que
utilizará un desarrollador la mayoría del tiempo. El Plugin de Eclipse es
compatible con Eclipse 3.1 y versiones superiores.

10.1. Añadir proyectos al control de código fuente

Para poner un proyecto existente bajo control de código fuente, primero es
necesario que exista un espacio de trabajo de Plastic SCM que contenga el
proyecto sobre el que se va a trabajar. Para este ejemplo, se asumirá el espacio
de trabajo de Plastic SCM se encuentra en ‘c:\wks’, y que el proyecto tiene la
siguiente estructura:

C:\wks
C:\wks\project
C:\wks\project\src\...

Se abrirá el proyecto en Eclipse de la manera habitual. Para añadir el proyecto

por primera vez a Plastic SCM, seleccionar el directorio de proyecto desde el
explorador de paquetes o desde el navegador, botón derecho, menú Team,
opción ‘Share Project’.

92
 Manual de Usuario

Figura 93: Opción para compartir el proyecto

Eclipse pregunta qué control de versiones debe utilizar.

Figura 94: Selección del control de versiones que se va a utilizar: Plastic

SCM

Al seleccionar Plastic SCM, hay que indicar al Plugin dónde puede encontrar el
ejecutable ‘cm.exe’. Normalmente se encontrará en el directorio ‘Archivos de
programa\Plastic SCM\client’, salvo que se haya especificado otra ubicación en la
instalación.

93
 Manual de Usuario

Figura 95: Ruta del ejecutable para la instalación de Plastic SCM

De esta manera se crea el enlace entre el proyecto y Plastic SCM. El siguiente

paso es añadir los ítems propiamente. Se puede añadir todo el proyecto o sólo
una parte del mismo, si bien lo normal es añadirlo entero. Para ello, con el
directorio de proyecto todavía seleccionado, botón derecho, menú Team, opción
‘Add to Plastic SCM recursively’

Figura 96: Opción para añadir el proyecto a Plastic SCM

Una vez añadidos, los ítems permanecen desprotegidos, como denota el tick gris
que aparece al lado de cada uno de ellos:

Figura 97: Elementos desprotegidos en Eclipse

Para completar la importación inicial, es necesario protegerlos. Con el directorio
de proyecto seleccionado, botón derecho, menú Team, opción ‘Check in
recursively’ los protegerá, y el tick gris cambia a un pequeño cilindro naranja,
indicando que están protegidos.

94
 Manual de Usuario

Figura 98: Protección de los elementos del proyecto

Ahora el proyecto está listo para ser usado por varios desarrolladores.

10.2. Abrir proyectos existentes en el control de código

fuente
Cuando otro desarrollador va a usar un proyecto que ha sido previamente
añadido, tiene que crear un espacio de trabajo y hacer una operación de update,
con lo que se hará la copia del proyecto desde el repositorio. Es posible hacer
esta operación desde la interfaz gráfica o desde la línea de comandos:

cm update .

Una vez realizado este paso, sólo hay que abrir el proyecto en Eclipse, y con el
directorio de proyecto seleccionado en el explorador de paquetes o en el
navegador, menú Team, opción ‘Share Project’, como en el caso anterior. Una
vez completado el proceso de enlace, como en el apartado anterior, los ítems ya
se encuentran listos para trabajar.

10.3. Operaciones básicas

Todas las operaciones disponibles desde Eclipse se encuentran en el menú de
contexto Team cuando se hace click con el botón derecho sobre un ítem del
proyecto.

95
 Manual de Usuario

Figura 99: Operaciones del Plugin de Eclipse

A continuación se detallan todas las operaciones:
• Add to Plastic SCM: pone los ítems seleccionados bajo control de código
fuente. Los ítems quedan desprotegidos.
• Add to Plastic SCM recursively: lo mismo que la opción anterior, pero si
los ítems seleccionados son directorios, añade también sus contenidos.
• Check in: protege los ítems seleccionados.
• Check in recursively: lo mismo que la opción anterior, pero si los ítems
seleccionados son directorios, protege también sus contenidos.
• Check out: desprotege los ítems seleccionados. Como se ha señalado con
anterioridad, por defecto los ítems son desprotegidos de forma
automática cuando se trata de hacer alguna modificación en ellos. Este
comportamiento puede cambiarse en el cuadro de preferencias de Plastic
SCM en Eclipse como se describe más adelante.
• Check out recursively: lo mismo que la opción anterior, pero si los ítems
seleccionados son directorios, desprotege también sus contenidos.
• Undo checkout: deshace la desprotección de los elementos seleccionados,
volviendo al estado que tenían antes de ser desprotegidos.
• Update: hace una operación de update sobre los ítems seleccionados. La
operación de update siempre es recursiva, por lo que si algún ítem es un
directorio, se actualizarán también sus contenidos.
• Refresh State: refresca el estado (protegidos o desprotegidos) de los
ítems seleccionados. Se suele emplear cuando los ítems han sido
manipulados fuera del entorno de Eclipse, para que éste vuelva a saber
qué operaciones puede aplicarles dependiendo de su estado.
• Diff with previous: Muestra las diferencias de la versión actual del ítem
con su revisión padre. Si el ítem está desprotegido se muestran las

96
 Manual de Usuario

diferencias que hay entre la desprotección y el estado anterior de la

desprotección.
• Version Tree: Muestra el árbol de versiones tridimensional del ítem
seleccionado.
• Remove from Plastic SCM: elimina el ítem del proyecto y del control de
versiones. Naturalmente las versiones previamente almacenadas del ítem
se siguen conservando en el repositorio.
• Unbind project from Plastic SCM source control: desconecta el proyecto
del control de versiones. Los pasos para volver a enlazarlo se han
descrito en el punto 10.2.
Algunas de estas operaciones pueden hacerse a través de la barra de botones de
Plastic SCM que tiene este aspecto:

Figura 100: Barra de herramientas de Plastic SCM en Eclipse

Los botones se corresponden, de izquierda a derecha, con éstas operaciones:
• Add to Plastic SCM: añadir el ítem seleccionado al control de versiones.
• Refresh State: refresca el estado de los ítems seleccionados.
• Version Tree: muestra el árbol de versiones del ítem seleccionado.
• Diff with previous: Muestra las diferencias de la versión actual con la
anterior.
• Check in: protege los ítems seleccionados.
• Checkout: desprotege los elementos seleccionados.
• Undo checkout: Deshace la desprotección de los ítems seleccionados.

10.4. Soporte de refactor

Plastic SCM ofrece soporte completo a las operaciones de refactor, en especial de
aquellas que implican renombrados y movimiento de ítems de un directorio a
otro.

Nota para Eclipse 3.1: Debido a una limitación en la implementación de Eclipse

3.1 que ha sido solucionada en Eclipse 3.2, el refactor para renombrar una clase
o package puede mostrar un error al finalizar, como el que se muestra en la
figura.

97
 Manual de Usuario

Este comportamiento es debido a la forma en que Eclipse arbitra la operación de

refactor y la comunicación con plugin de control de versiones. Es suficiente con
pulsar el botón ‘back’ y ‘next’ de nuevo, con lo que la operación se completa
correctamente.

10.5. Preferencias
Es posible modificar las preferencias asociadas al Plugin de Plastic SCM para
Eclipse en el menú Window, Preferences. En el árbol de opciones, seleccionar
Team / Plastic SCM, y aparecerá un cuadro como el de la figura.

Figura 101: Cuadro de preferencias

Es posible configurar las siguientes opciones:

• Command line executable: ruta al ejecutable de Plastic SCM.
Normalmente se fija una vez en el primer uso, y se dejará fijo. Es posible
hacer que este parámetro apunte a otra instalación diferente de Plastic
SCM.

98
 Manual de Usuario

• Automatic checkout file to modify: marcada por defecto, indica si Plastic

SCM debe desproteger un ítem cuando se modifica en el editor de Eclipse.

10.6. Decoradores
Los decoradores (decorators) son los pequeños iconos que aparecen al lado de
cada ítem indicando su estado (protegido o desprotegido). Por defecto quedan
activados al instalar el Plugin de Plastic SCM, si bien es posible activarlos o
desactivarlos en el menú Window, Preferences. En el árbol de opciones,
seleccionar General / Appearance / Label Decorators. Aparece un cuadro como el
de la figura, en el que se pueden activar o desactivar los decoradores.

Figura 102: Decoradores de Plastic SCM en Eclipse

10.7. La Perspectiva Plastic SCM

Esta perspectiva incluye una consola con el estado de las operaciones que se
realizan en Plastic SCM, una vista del espacio de trabajo actual, que incluye
ramas y etiquetas y finalmente una vista de elementos desprotegidos. Además
incluye la vista de ‘Package Explorer’ de la perspectiva de Java.

Para abrir esta vista, haga clic sobre ‘Open Perspective’ en Eclipse , después
sobre ‘Other’ y seleccione ‘Plastic SCM’ de las opciones que aparecen en la lista.

99
 Manual de Usuario

Figura 103: Lista de perspectivas disponibles en Eclipse, destacando la

perspectiva de Plastic SCM
A continuación describimos detalladamente para qué sirve cada vista:

10.7.1. Vista de consola

Figura 104: Vista de consola de la perspectiva Plastic SCM

En esta vista podemos visualizar el resultado de algunas de las operaciones
realizadas contra el servidor de Plastic SCM, la conexión con el mismo, si el
plugin está operativo o no, etc.

10.7.2. Vista de Explorador de espacios de trabajo

Figura 105: Vista de explorador de espacios de trabajo de la perspectiva

Plastic SCM
Esta vista nos permite visualizar el selector del espacio de trabajo, cambiarlo,
listar ramas, ordenarlas, crear ramas nuevas, hacer merges, ver las propiedades
de una rama y hacer rebases, crear etiquetas y establecer etiquetas. Veamos
detalladamente cada una de estas operaciones:
Haciendo clic derecho sobre el espacio de trabajo podemos:
Obtener: Permite actualizar el espacio de trabajo.
Cambiar selector del espacio de trabajo: Abre un cuadro de texto en el que
se puede introducir el nuevo selector de espacio de trabajo.
Haciendo clic derecho sobre una rama listada en el desplegable ‘Ramas’:
Crear rama hija: Le permite crear una nueva rama hija de la rama
seleccionada.

100
 Manual de Usuario

Cambiar a esta rama: Cambia el selector del espacio de trabajo, apuntando a

la rama seleccionada.
Merge desde esta rama: Permite realizar una operación de merge desde la
rama seleccionada hacia la rama activa en ese momento en el espacio de
trabajo. El proceso de merge es muy similar a cómo se lleva a cabo en la
interfaz gráfica de Plastic.

Figura 106: Diálogo de merge de la perspectiva de Plastic SCM

Propiedades: Solamente disponible para ramas que no sean principales,

permite visualizar las propiedades de la rama seleccionada, tal y como se
mostraría en la vista de propiedades de una rama en la interfaz gráfica de
Plastic.

Figura 107: Diálogo de propiedades de una rama

Haciendo clic derecho sobre ‘Etiquetas’:
Crear etiqueta nueva: Permite crear una nueva etiqueta.
Si se despliega la lista de ‘Etiquetas’, se tienen las siguientes opciones:

101
 Manual de Usuario

Cambiar a esta etiqueta: Permite cambiar el selector del espacio actual a esta
etiqueta. Nótese que la etiqueta es un punto fijo, de modo que no se puede
hacer desprotecciones cuando el selector apunta a una etiqueta.
Etiquetar estado actual: Permite etiquetar las revisiones de los ítems
protegidos actualmente en el espacio de trabajo. Esta operación no se permite si
hay elementos desprotegidos.
Merge desde esta etiqueta: Aparece el diálogo de merge antes descrito para
una rama, sólo que esta vez el origen del merge es la etiqueta seleccionada.

10.7.3. Vista de Desprotecciones pendientes

Figura 108: Vista de desprotecciones pendientes de la perspectiva

Plastic SCM
Esta vista le permitirá visualizar la lista de elementos que tiene desprotegidos en

un determinado momento. Es posible proteger o deshacer desprotección

de todos (pulsando sobre ) o solamente de aquellos seleccionados en el

listado (pulsando Ctrl+clic).
Además, haciendo doble clic sobre cualquiera de los ítems listados se abrirá la
herramienta de diferencias de Plastic, permitiéndole comparar los cambios
realizados en la sesión de trabajo con la última versión protegida en el servidor.

102
 Manual de Usuario

11. Integración con JDeveloper

La integración con JDeveloper permitirá a los usuarios trabajar con Plastic SCM
1.5 o superior desde cualquier entorno de desarrollo JDeveloper 10 o superior.
En este capítulo se describirán las principales operaciones que permitirán
trabajar con fluidez con el sistema desde JDeveloper.
Antes de comenzar a utilizar la herramienta hay que saber cuál es la localización
del repositorio de PlasticSCM en el que se guardarán los proyectos de
JDeveloper.

11.1. Añadir proyectos al control de código fuente

Esta operación se realiza cuando el proyecto con el que se quiere trabajar, existe
en disco, pero aún no está bajo el control de Plastic SCM. Los ficheros creados
en JDeveloper antes de utilizar PlasticSCM deben importarse dentro del
repositorio de PlasticSCM y desprotegerlos.
Requisitos:
• Los archivos de proyecto deben estar ubicados dentro de un espacio de
trabajo en la máquina del usuario.
• El plugin para JDeveloper de Plastic SCM debe de estar instalado.
Pasos a seguir:
• Abrir el proyecto con JDeveloper
• Pulsar con el botón derecho, menú Versioning, opción Select Version
System, PlasticSCM como muestra la Figura 109

103
 Manual de Usuario

Figura 109: Selección de Plastic SCM como control de versiones

• Indicar en Tools, Preferences, Versioning, PlasticSCM, directorio donde
está instalado PlasticSCM como se puede ver en la Figura 110.

Figura 110: Localización de Plastic SCM

En el caso de que la localización de Plastic SCM no se haya indicado en este
menú, JDeveloper lanzará un error como el que muestra la Figura 111

104
 Manual de Usuario

Figura 111: Preferencia vacía

• Después en el Proyecto, seleccionar botón derecho, Versioning, Refresh
Status para para indicar que el proyecto está dentro de un espacio de
trabajo:

Figura 112: Actualizar el estado

• Por último, en el Proyecto seleccionar botón derecho, seleccionar Add to
Plastic SCM Recursively desde el menú Versioning para añadir el proyecto
al control de versiones de PlasticSCM.

11.2. Operaciones
En el menú contextual de cada fichero de JDeveloper, hay una serie de
operaciones básicas relacionadas con el control de código fuente.

105
 Manual de Usuario

Figura 113: Operaciones de Plastic SCM desde JDeveloper

• Add to Plastic SCM: Añade el elemento seleccionado.

• Add to Plastic SCM recursively: Añade ese elemento y todos los que
jerárquicamente se encuentren bajo el mismo.
• Check in: Protege los elementos seleccionados.
• Check out: Desprotege los elementos seleccionados.
• Undo checkout: Cancela la desprotección de los elementos
seleccionados, dejándolos como estaban antes de la desprotección.
• Update: Obtiene la última versión del elemento seleccionado.
• Diff with previous: Muestra diferencias entre la revisión del espacio de
trabajo y la revisión del servidor.
• Version tree: Obtiene todo el árbol de versiones y a partir de él se
pueden obtener la diferencia entre dos versiones cualesquiera.
• Remove from Plastic: Elimina el proyecto del control de versiones.
• Refresh status: Actualiza el estado del proyecto.
Si el usuario intenta cambiar un elemento sin haberlo desprotegido
anteriormente, el sistema lanzará el error que se muestra en Figura 114 y el
usuario podrá desproteger el elemento.

Figura 114: Error al hacer cambios sin desproteger

106
 Manual de Usuario

11.3. Decoradores
Los decoradores son pequeños iconos que se muestran junto a un elemento para
mostrar su estado. Se activan por defecto al instalar la integración con Plastic
SCM.
Los decoradores para JDeveloper son los siguientes:

Indica que el elemento no está dentro de un espacio de trabajo o que no ha

sido reconocido por el cliente de Plastic SCM.

Indica que el elemento es privado.

Indica que el elemento está desprotegido.

Indica que el elemento está protegido.

107
 Manual de Usuario

12. IntelliJ 5 Plug in

El Plugin de IntelliJ permite a los usuarios trabajar con Plastic SCM desde el
entorno integrado de IntelliJ, ofreciendo las operaciones más comunes. El plugin
es compatible con la versión de IntelliJ 5.1.

12.1. Configurar el Plug in

Para poder trabajar con el plugin, éste ha de ser previamente configurado. Para
ello, desde IntelliJ 5.1, haga clic sobre ‘File’ y después sobre ‘Settings’, o bien
utilice el atajo de teclado ‘Ctrl+Alt+S’. Aparece la ventana de configuración de
IntelliJ5.1.

108
 Manual de Usuario

Figura 115: Ventana de Settings de IntelliJ5.1

De la lista de opciones que aparecen, haga clic sobre ‘Version Control’. En el
diálogo que se abre, seleccione de la lista ‘PlasticSCM’ y pulse sobre ‘Configure’.

Figura 116: Diálogo de configuración de control de versiones de

IntelliJ5.1
Aparece la ventana de configuración del plugin, en la cual es necesario indicar la
ruta al comando ‘cm.exe’ (‘cm’ en linux). Si se deja este campo en blanco se

109
 Manual de Usuario

buscará una ruta por defecto basada en el directorio de instalación por defecto
de Plastic. Si se teclea simplemente ‘cm.exe’ o ‘cm’ (linux), el programa también
buscará este comando en la ruta de instalación por defecto.

Figura 117: Configuración del plugin de PlasticSCM para IntelliJ5.1

Una vez indicado este dato, se puede pulsar sobre ‘Test Connection’ para
verificar que la ruta dada es correcta. Comprobado esto, podemos cerrar el
diálogo haciendo clic sobre ‘OK’. De este modo, el plugin de PlasticSCM para
IntelliJ5.1 queda correctamente configurado.

Figura 118: Resultado satisfactorio de un Test Connection.

12.2. Checkout from Version Control

Esta operación nos permitirá importar un proyecto alojado en un repositorio
PlasticSCM, de modo que una vez que se ha importado dicho proyecto podremos
trabajar con él desde IntelliJ 5.1.

110
 Manual de Usuario

Figura 119: Pantalla principal de IntelliJ5.1, destacando la opción de

Check out from Version Control
Para realizar esto es imprescindible tener bien configurado el plugin; para ello se
procederá como se indica en el apartado anterior. El servidor contra el que se
realiza la petición de importación es el servidor contra el que está configurado el
cliente de PlasticSCM. Haga clic sobre esta opción del menú principal de
IntelliJ5.1 y seleccione PlasticSCM como control de versiones a utilizar.
Aparece un asistente en el cual se indicará el repositorio donde están los datos a
obtener, especificando, así mismo, la rama (branch) o la etiqueta (label) de los
contenidos a importar. Obligatoriamente los contenidos deberán ser
especificados mediante una rama o una etiqueta. Para elegir entre una opción u
otra, haga clic sobre el repositorio a utilizar, después haga clic sobre la opción
deseada y a continuación sobre el botón “…” para seleccionar la rama o etiqueta,
según el caso.

111
 Manual de Usuario

Figura 120: Selección de repositorio, rama y etiqueta.

Pulse ‘OK’ para ir al siguiente paso. A continuación aparece una ventana donde
se indicará el espacio de trabajo donde se han de traer los contenidos. Podemos
elegir un espacio de trabajo de entre los que aparecen listados, ya existentes en
el servidor, o bien crear uno nuevo.

112
 Manual de Usuario

Figura 121: Selección de workspace.

Para esto último, seleccione ‘Create new’… e indique el nombre del espacio de
trabajo y la ruta en la que se va a ubicar en el disco local.

Figura 122: Diálogo de creación de un nuevo workspace.

Una vez seleccionado el espacio de trabajo que se utilizará para descargar los
contenidos, se puede acceder al siguiente paso pulsando sobre ‘Next’.
En este último paso se muestra un resumen de la información que se utilizará
para importar los contenidos del repositorio. Verificada esta información, puede
pulsar sobre ‘Finish’ y el sistema traerá los contenidos de la rama o etiqueta
seleccionada, del repositorio indicado al espacio de trabajo especificado. Ahora
es posible abrir el proyecto con IntelliJ5.1 del mismo modo que se abriría
cualquier otro proyecto con IntelliJ5.1.

113
 Manual de Usuario

Nota: Todo módulo IDEA enlazado a PlasticSCM deberá estar en uno y sólo un
espacio de trabajo local de la máquina del usuario. En otro caso el plugin se
deshabilitará. Sin embargo, pueden convivir módulos enlazados a PlasticSCM con
módulos enlazados a otros controles de versiones, o incluso con módulos no
enlazados a ningún control de versiones.

12.3. Breve reseña sobre el estado de los ítems.

Para cualquier proyecto controlado por PlasticSCM, en la vista ‘Project’ los
nombres de los ítems aparecen con un determinado código de colores que indica
el estado de tal ítem en el control de versiones.
Si el ítem tiene color granate el elemento es privado, es decir, no está bajo el
control de versiones; si es de color verde se trata un elemento recién añadido; si
tiene color azul significa que está desprotegido para ser editado y por último si el
color es negro quiere decir que el elemento está protegido.

Figura 123: Muestra del código de colores utilizado para resaltar el

estado de los ítems.
Usuario

12.4. Abrir proyectos existentes en el control de código

fuente
Una vez se ha importado un proyecto de PlasticSCM, es posible abrirlo mediante
el menú ‘File’ y después ‘Open Project’ de IntelliJ5.1.
Si el proyecto está controlado por PlasticSCM se verá el código de colores en los
nombres de los ítems que indicábamos en la sección anterior.
Una vez abierto el proyecto, es conveniente realizar una operación de Obtener
para garantizar que tenemos los últimos contenidos del proyecto en nuestro
espacio de trabajo. Para ello haremos clic derecho sobre la raíz del proyecto y
elegiremos la opción ‘Update Directory’. Otra opción es hacer clic en el menú
Version Control de IntelliJ5.1 y seleccionar la opción ‘Update Project’. Para más
información sobre operaciones aplicables a los elementos de un proyecto,
consulte el siguiente apartado.

12.5. Operaciones básicas

Todas las operaciones disponibles desde IntelliJ5.1 se encuentran en el menú de
contexto PlasticSCM que aparece al hacer clic derecho sobre un ítem o sobre el
editor, o bien al hacer clic sobre el menú de IntelliJ5.1 ‘Version Control’ y
después sobre ‘PlasticSCM’.

114
 Manual de Usuario

Manual de
Usuario

Figura 124: Operaciones de PlasticSCM aplicables a un ítem.

A continuación se detallan estas operaciones:
• Checkin File: Permite proteger los cambios en los ficheros seleccionados.
Al pulsar sobre esta opción, aparece el diálogo de protección de ficheros,
en el cual se podrá indicar a PlasticSCM si ha de ignorar los elementos
que no han sufrido cambios, indicar comentarios para la operación (o
elegir un comentario de los utilizados anteriormente, mediante la opción
‘History’), y marcar o desmarcar otras opciones que IntelliJ5.1 puede
realizar antes de comenzar a proteger, como por ejemplo optimizar
importaciones, reformatear el código o buscar errores en el código.

115
 Manual de Usuario

Figura 125: Diálogo de checkin.

• Checkin Directory: Permite proteger los cambios en los elementos
contenidos en un directorio, recursivamente. Además de las opciones
mostradas en el diálogo de ‘Checkin File’, se puede visualizar la
estructura antes de los cambios y después de los cambios realizados en el
directorio. IntelliJ5.1 proporciona, además, un código de colores que
permite observar qué elementos han cambiado, han sido añadidos o se
han borrado. Las opciones disponibles son: realizar un ‘Commit’
(protección de los ficheros cambiados o añadidos en el repositorio de
Plastic SCM) o bien ‘Rollback’ (deshacer los últimos cambios y volver a la
revisión anterior).

116
 Manual de Usuario

Figura 126: Diálogo de checkin para directorios.

• Rollback: Deshace los últimos cambios que se han hecho sobre el ítem
seleccionado y se vuelve a la revisión anterior almacenada en el servidor
de Plastic SCM. En caso de aplicarse sobre un directorio, se deshacen los
cambios recursivamente en todos los elementos del directorio.
• Update File: Permite obtener los últimos cambios registrados en el
repositorio de PlasticSCM en el que se encuentra un fichero para la rama
o etiqueta activa en el selector del proyecto. Tras ejecutarse esta acción
se mostrará un informe con los ficheros que se han creado, borrado y
modificado.
• Update Directory: Tiene el mismo comportamiento que la opción
anterior pero aplicado a directorios de forma recursiva. Nuevamente, se
aplica para la rama o etiqueta activa en el selector del proyecto.
• Edit (Ctrl+O): Aplicado a un fichero, lo desprotege para su edición;
aplicado a un directorio, desprotege recursivamente todos los ficheros
contenidos en dicho directorio. Esta operación puede ser realizada
automáticamente al editar el fichero en el panel de edición de IntelliJ.
Aparecerá un aviso de IntelliJ5.1 indicando si se desea eliminar la
protección de sólo lectura; al pulsar sobre OK PlasticSCM desprotege
automáticamente el elemento.

117
 Manual de Usuario

Figura 127: Diálogo de IDEA para quitar la propiedad de sólo lectura de

un ítem.
• Add (Ctrl+A): Permite añadir elementos al control de versiones.
Aplicado sobre un fichero, añade dicho fichero. Aplicado sobre un
directorio, añade recursivamente el directorio y todos sus contenidos. Los
directorios añadidos de este modo quedan en estado protegido.
• Unco all unchanged files: Deshace la desprotección de los elementos
seleccionados que están en estado desprotegido y no han sido
modificados por el usuario. Aplicado a un directorio, deshace el estado de
desprotección para aquellos elementos dentro del directorio que estaban
desprotegidos y no han sufrido ningún cambio.
• Show History: Muestra el historial de revisiones de un fichero, indicando
para cada revisión la fecha, el autor y el comentario que se introdujo en
la creación de dicha revisión.

Figura 128: Vista de historial de un ítem.

Se puede realizar una serie de operaciones con las revisiones que se muestran
en la tabla, como comparar el contenido de dos revisiones seleccionadas,
comparar la versión local con una de las mostradas en la tabla o recuperar una
revisión concreta.
• Compare with the Same Repository Version: Compara la versión
local con la última versión que existe en la misma rama.
• Compare with the Last Repository Version: Compara la versión local
con la última versión que existe en la misma rama.

Nota: Existe un problema conocido con la vista de historia en IDEA, a la hora de

marcar en negrita la revisión que se está cargada localmente. Para que IDEA
muestre correctamente en negrita ésta revisión, es necesario cerrar y volver a
abrir la vista de historia.

• Annotate: Permite visualizar quién hizo los cambios sobre cada línea
del fichero seleccionado, así como otra información relevante.

118
 Manual de Usuario

Figura 129: Comando Annotate para un fichero controlado por

PlasticSCM.
Además, en el menú ‘Version Control’, ‘PlasticSCM’ tenemos disponibles las
siguientes opciones:

Figura 130: Menú Version Control de IntelliJ5.1, con las opciones de

PlasticSCM.
• Commit Project: Protege todos los cambios realizados en el proyecto.
Aparece el cuadro de diálogo de Proteger directorio, expuesto antes.
• Update Project: Realiza una operación de obtención de todo el proyecto,
buscando cambios realizados en los elementos del proyecto que han sido
registrados en el repositorio. Es posible forzar esta operación, es decir,
obtener de nuevo la última revisión de todos los ficheros actualizados o
cambiados.
También es posible desde esta opción especificar un cambio de rama o de
etiqueta. Con ello se cargará el contenido de la rama deseada en el espacio de
trabajo. Este cambio de rama o etiqueta no es posible realizarlo a no ser que se
seleccione esta opción del menú ‘Version Control’ o bien se seleccione la raíz de
todos los módulos cargados y se haga clic derecho, seleccionando ‘PlasticSCM’,

119
 Manual de Usuario

‘Update Directory’. En otro caso solamente se podrán actualizar los contenidos

del módulo, directorio o fichero seleccionado sin cambiar de rama ni de etiqueta.

Figura 131: Diálogo de actualización de proyecto

Nota: Como se ha indicado, una vez terminada la operación se muestra un

resumen de la operación con los ficheros creados, actualizados y borrados. En la
lista de elementos modificados se muestran los elementos cambiados fuera del
control de versiones (lista ‘Modified’). Si se seleccionan estos elementos, se hace
clic derecho y se pulsa sobre ‘Update Files’ podremos hacer una operación de
update con la opción de ‘Force update files’ marcada por defecto.

• Merge from branch or label: Permite realizar una operación de merge

desde una rama o una etiqueta seleccionada en el diálogo que se abre al
pulsar sobre esta opción. A continuación, si se hace clic sobre ‘Find
Merges’, el sistema buscará los merges pendientes entre los contenidos
cargados actualmente en el espacio de trabajo y la rama o etiqueta
seleccionada. Si hay merges pendientes, se listarán, y haciendo clic sobre
‘Start Merges’ el sistema comenzará a unir los cambios. Una vez
terminada dicha operación, pulsaremos sobre ‘Close’. Los elementos
afectados quedan en estado desprotegido para que pueda verificar que el
resultado del merge es el deseado. En caso contrario es posible realizar
una operación de Rollback desde la raíz del módulo para descartar los
cambios propuestos por la operación de Merge.

120
 Manual de Usuario

Figura 132: Diálogo de merge.

• Create workspace: Permite crear un nuevo workspace para un proyecto
no asociado a ningún workspace. Para ello, se abre un diálogo que nos
permitirá indicar el repositorio que utilizará el espacio de trabajo, su
nombre y su ruta.

12.6. Soporte de refactor

PlasticSCM ofrece soporte a algunas operaciones de refactor, en especial
aquellas que implican renombrados, borrados y movimiento de ítems de un
directorio a otro.
Las modalidades de refactor de ítems que actualmente soporta PlasticSCM son:
• Move
• Rename
• Delete
Estas operaciones conllevan operaciones en disco que se hacen extensibles
automáticamente al control de versiones PlasticSCM.

Nota: En el caso de borrar varios ficheros, si se hace clic sobre el menú

contextual ‘Delete’ se realiza una desprotección del directorio y se eliminan los
ficheros uno a uno; por ello es más eficiente y recomendable utilizar la opción
‘Safe Delete’ del menú ‘Refactor’, que realiza el borrado de una sola pasada,
efectuando una operación de refactor real.

121
 Manual de Usuario

13. IntelliJ 8 Plug in

El Plugin de IntelliJ permite a los usuarios trabajar con Plastic SCM desde el
entorno integrado de IntelliJ, permitiendo al usuario realizar las operaciones más
comunes. El plugin es compatible con la versión de IntelliJ 8.1.

13.1. Configurar el Plug in

Para poder trabajar con el plugin, éste ha de ser previamente configurado. Para
ello, desde IntelliJ 8, haga clic sobre ‘File’ y después sobre ‘Settings’, o bien
utilice el atajo de teclado ‘Ctrl+Alt+S’. Aparece la ventana de configuración de
IntelliJ 8.

Figura 133: Ventana de configuración de IntelliJ 8

122
 Manual de Usuario

En la vista de la derecha aparece el proyecto cargado y el VCS asociado. Aquí

podrá seleccionar Plastic SCM de la lista para asociar Plastic al proyecto.

Figura 134: Detalle de la asociación del proyecto a Plastic SCM.

Veamos cómo configurar el plugin para que el proyecto pueda utilizar Plastic
SCM como sistema de control de versiones. De la lista de opciones que aparece a
la izquierda, haga clic sobre ‘Version Control’. En la sublista desplegada,
seleccione VCSs y Plastic SCM.

Figura 135: Configuración del plugin de Plastic SCM para IntelliJ 8

Aparece la ventana de configuración del plugin, en la cual es necesario indicar la
ruta al comando ‘cm.exe’ (‘cm’ en linux). Si se deja este campo en blanco se
buscará una ruta por defecto basada en el directorio de instalación por defecto
de Plastic. Si se teclea simplemente ‘cm.exe’ o ‘cm’ (linux), el programa también
buscará este comando en la ruta de instalación por defecto.
Una vez indicado este dato, se puede pulsar sobre ‘Test Connection’ para
verificar que la ruta dada es correcta. Comprobado esto, podemos cerrar el
diálogo haciendo clic sobre ‘OK’. De este modo, el plugin de PlasticSCM para
IntelliJ 8 queda correctamente configurado. Otras opciones ofrecidas son:
configurar el cliente de Plastic y habilitar/deshabilitar el plugin para trabajar
conectado/desconectado del control de versiones.

123
 Manual de Usuario

Figura 136: Resultado satisfactorio de un Test Connection.

13.2. Checkout from Version Control

Esta operación nos permitirá importar un proyecto alojado en un repositorio
PlasticSCM, de modo que una vez que se ha importado dicho proyecto podremos
trabajar con él desde IntelliJ 8.

Figura 137: Pantalla principal de IntelliJ 8, destacando la opción de

Check out from Version Control
Para realizar esto es imprescindible tener bien configurado el plugin; para ello se
procederá como se indica en el apartado anterior. El servidor contra el que se
realiza la petición de importación es el servidor contra el que está configurado el
cliente de Plastic SCM. Haga clic sobre esta opción del menú principal de IntelliJ
8 y seleccione Plastic SCM como control de versiones a utilizar.
Aparece un asistente en el cual se indicará el repositorio donde están los datos a
obtener, especificando, así mismo, la rama (branch) o la etiqueta (label) de los
contenidos a importar. Obligatoriamente los contenidos deberán ser
especificados mediante una rama o una etiqueta. Para elegir entre una opción u
otra, haga clic sobre el repositorio a utilizar, después haga clic sobre la opción

124
 Manual de Usuario

deseada y a continuación sobre el botón “…” para seleccionar la rama o etiqueta,

según el caso.

Figura 138: Selección de repositorio y rama o etiqueta.

Pulse ‘OK’ para ir al siguiente paso. A continuación aparece una ventana donde
se indicará el espacio de trabajo donde se han de traer los contenidos. Podemos
elegir un espacio de trabajo de entre los que aparecen listados, ya existentes en
el servidor, o bien crear uno nuevo.

Figura 139: Selección de workspace como destino de la operación.

125
 Manual de Usuario

Para esto último, seleccione ‘Create new…’ e indique el nombre del espacio de
trabajo y la ruta en la que se va a ubicar en el disco local.

Figura 140: Diálogo de creación de un nuevo workspace.

Una vez seleccionado el espacio de trabajo que se utilizará para descargar los
contenidos, se puede acceder al siguiente paso pulsando sobre ‘Next’.

Figura 141: Resumen de la operación de Check Out from Version Control

que se va a realizar.
En este último paso se muestra un resumen de la información que se utilizará
para importar los contenidos del repositorio. Verificada esta información, puede
pulsar sobre ‘Finish’ y el sistema traerá los contenidos de la rama o etiqueta
seleccionada, del repositorio indicado al espacio de trabajo especificado. Ahora
es posible abrir el proyecto con IntelliJ 8 del mismo modo que se abriría
cualquier otro proyecto con IntelliJ 8.

126
 Manual de Usuario

Nota: Todo módulo de IntelliJ enlazado a Plastic SCM deberá estar en uno y sólo
un espacio de trabajo local de la máquina del usuario. En otro caso el plugin se
deshabilitará.

13.3. Breve reseña sobre el estado de los ítems.

Para cualquier proyecto controlado por Plastic SCM, en la vista ‘Project’ los
nombres de los ítems aparecen con un determinado código de colores que indica
el estado de tal ítem en el control de versiones.
Si el ítem tiene color granate el elemento es privado, es decir, no está bajo el
control de versiones; si es de color verde se trata un elemento recién añadido; si
tiene color azul significa que está desprotegido para ser editado y por último si el
color es negro quiere decir que el elemento está protegido.

Figura 142: Muestra del código de colores utilizado para resaltar el

estado de los ítems.
Usuario

13.4. Abrir proyectos existentes en el control de código

fuente
Una vez se ha importado un proyecto de Plastic SCM, es posible abrirlo mediante
el menú ‘File’ y después ‘Open Project’ de IntelliJ 8.
Si el proyecto está controlado por Plastic SCM se verá el código de colores en los
nombres de los ítems que indicábamos en la sección anterior.
Una vez abierto el proyecto, es conveniente realizar una operación de
actualización de contenidos para garantizar que tenemos las últimas revisiones
del proyecto en nuestro espacio de trabajo. Para ello haremos clic derecho sobre
la raíz del proyecto y elegiremos la opción ‘Update Directory’. Otra opción es
hacer clic en el menú Version Control de IntelliJ 8 y seleccionar la opción ‘Update
Project’. Para más información sobre operaciones aplicables a los elementos de
un proyecto, consulte el siguiente apartado.

13.5. Operaciones básicas

Todas las operaciones disponibles desde IntelliJ 8 se encuentran en el menú de
contexto Plastic SCM que aparece al hacer clic derecho sobre un ítem o sobre el
editor, o bien al hacer clic sobre el menú de IntelliJ 8 ‘Version Control’ y después
sobre ‘Plastic SCM’.

127
 Manual de Usuario

Manual de
Usuario

Figura 143: Operaciones de Plastic SCM aplicables a un ítem.

A continuación se detallan estas operaciones:
• Checkin File: Permite proteger los cambios en los ficheros seleccionados.
Al pulsar sobre esta opción, aparece el diálogo de protección de ficheros,
en el cual se podrá indicar a Plastic SCM si ha de ignorar los elementos
que no han sufrido cambios, indicar comentarios para la operación, y
marcar o desmarcar otras opciones que IntelliJ 8 puede realizar antes de
comenzar a proteger, como por ejemplo optimizar importaciones,
reformatear el código o buscar errores en el código. IntelliJ 8
proporciona, además, un código de colores que permite observar qué
elementos han cambiado, han sido añadidos o se han borrado.

128
 Manual de Usuario

Figura 144: Diálogo de checkin.

• Checkin Directory: Abre un diálogo similar al anterior.
• Rollback: Deshace los últimos cambios que se han hecho sobre el ítem
seleccionado y se vuelve a la revisión anterior almacenada en el servidor
de Plastic SCM. En caso de aplicarse sobre un directorio, se deshacen los
cambios recursivamente en todos los elementos del directorio.
• Update File: Permite obtener los últimos cambios registrados en el
repositorio de Plastic SCM en el que se encuentra un fichero para la rama
o etiqueta activa en el selector del proyecto. Tras ejecutarse esta acción
se mostrará un informe con los ficheros que se han creado, borrado y
modificado.
• Update Directory: Tiene el mismo comportamiento que la opción
anterior pero aplicado a directorios de forma recursiva. Nuevamente, se
aplica para la rama o etiqueta activa en el selector del proyecto.
• Edit: Aplicado a un fichero, lo desprotege para su edición; aplicado a un
directorio, desprotege recursivamente todos los ficheros contenidos en
dicho directorio. Esta operación puede ser realizada automáticamente al
editar el fichero en el panel de edición de IntelliJ. Aparecerá un aviso de
IntelliJ 8 indicando si se desea eliminar la protección de sólo lectura; al
pulsar sobre OK Plastic SCM desprotege automáticamente el elemento.

129
 Manual de Usuario

Figura 145: Diálogo de IntelliJ para quitar la propiedad de sólo lectura

de un ítem.
• Add: Permite añadir elementos al control de versiones. Aplicado sobre un
fichero, añade dicho fichero. Aplicado sobre un directorio, añade
recursivamente el directorio y todos sus contenidos. Los directorios
añadidos de este modo quedan en estado protegido.
• Show History: Muestra el historial de revisiones de un fichero, indicando
para cada revisión la fecha, el autor y el comentario que se introdujo en
la creación de dicha revisión.

Figura 146: Vista de historial de un ítem.

Se puede realizar una serie de operaciones con las revisiones que se muestran
en la tabla, como comparar el contenido de dos revisiones seleccionadas,
comparar la versión local con una de las mostradas en la tabla o recuperar una
revisión concreta.
• Compare with the Same Repository Version: Compara la versión
local con la última versión que existe en la misma rama.
• Compare with the Last Repository Version: Compara la versión local
con la última versión que existe en la misma rama.
• Annotate: Permite visualizar quién hizo los cambios sobre cada línea del
fichero seleccionado, así como otra información relevante.

130
 Manual de Usuario

Figura 147: Comando Annotate para un fichero controlado por Plastic

SCM.
Además, en el menú ‘Version Control’, ‘Plastic SCM’ tenemos disponibles las
siguientes opciones:

131
 Manual de Usuario

Figura 148: Menú Version Control de IntelliJ 8, con las opciones de

Plastic SCM.
• Commit Changes: Protege todos los cambios realizados en el proyecto.
Aparece el cuadro de diálogo de checkin expuesto antes.
• Update Project: Realiza una operación de obtención de todo el proyecto,
buscando cambios realizados en los elementos del proyecto que han sido
registrados en el repositorio. Es posible forzar esta operación, es decir,
obtener de nuevo la última revisión de todos los ficheros actualizados o
cambiados.
También es posible desde esta opción especificar un cambio de rama o de
etiqueta. Con ello se cargará el contenido de la rama deseada en el espacio de
trabajo. Este cambio de rama o etiqueta no es posible realizarlo a no ser que se
seleccione esta opción del menú ‘Version Control’ o bien se seleccione la raíz de
todos los módulos cargados y se haga clic derecho, seleccionando ‘Plastic SCM’,
‘Update Directory’. En otro caso solamente se podrán actualizar los contenidos
del módulo, directorio o fichero seleccionado sin cambiar de rama ni de etiqueta.

132
 Manual de Usuario

Figura 149: Diálogo de actualización de proyecto

Así mismo, también es posible la creación de nuevas ramas, haciendo clic sobre
‘New…’. Se abre un diálogo como el siguiente, en el cual se indicará nombre,
rama padre, punto de partida y comentarios:

Figura 150: Diálogo de creación de una rama nueva

Nota: Como se ha indicado, una vez terminada la operación se muestra un

resumen con los ficheros creados, actualizados y borrados. En la lista de
elementos modificados se muestran los elementos cambiados fuera del control
de versiones (lista ‘Modified’).

• Merge from Plastic SCM branch or label: Permite realizar una

operación de merge desde una rama o una etiqueta seleccionada en el
diálogo que se abre al pulsar sobre esta opción. A continuación, si se
hace clic sobre ‘Find Merges’, el sistema buscará los merges pendientes
entre los contenidos cargados actualmente en el espacio de trabajo y la
rama o etiqueta seleccionada. Si hay merges pendientes, se listarán, y
haciendo clic sobre ‘Start Merges’ el sistema comenzará a unir los
cambios. Una vez terminada dicha operación, pulsaremos sobre ‘Close’.
Los elementos afectados quedan en estado desprotegido para que pueda

133
 Manual de Usuario

verificar que el resultado del merge es el deseado. En caso contrario es

posible realizar una operación de Rollback desde la raíz del módulo para
descartar los cambios propuestos por la operación de Merge.

Figura 151: Diálogo de merge.

• Create workspace: Permite crear un nuevo workspace para un proyecto
no asociado a ningún workspace. Para ello, se abre un diálogo que nos
permitirá indicar el repositorio que utilizará el espacio de trabajo, su
nombre y su ruta.

Figura 152: Diálogo de creación de workspace.

134
 Manual de Usuario

13.6. Soporte de refactor

Plastic SCM ofrece soporte a algunas operaciones de refactor, en especial
aquellas que implican renombrados, borrados y movimiento de ítems de un
directorio a otro.
Las modalidades de refactor de ítems que actualmente soporta Plastic SCM son:
• Move
• Rename
• Delete
Estas operaciones conllevan operaciones en disco que se hacen extensibles
automáticamente al control de versiones Plastic SCM.

Nota: En el caso de borrar ficheros, IntelliJ 8 opta por efectuar siempre un ‘Safe
Delete’, tanto si se ha seleccionado la opción ‘Delete’ como si se ha seleccionado
‘Refactor’->’Safe Delete’.

13.7. Trabajo fuera de línea (Work offline)

El plugin de Plastic SCM para IntelliJ8 permite un modo de trabajo en
desconexión con el servidor Plastic, de manera que podemos realizar acciones
básicas tales como add, check in, check out, movido y renombrado de ficheros,
etc., sin que el servidor Plastic tenga consciencia de estos cambios.

Figura 153: Opción de trabajar fuera de línea.

Para trabajar fuera de línea, haga clic en la opción ‘Work Offline’ que aparece en
el menú Plastic SCM, expuesto en una sección anterior.
Posteriormente, una vez se ha restaurado la conexión con el servidor se
ejecutarán tales acciones en el servidor Plastic SCM. Para volver al modo de
trabajo en línea, haga de nuevo clic en la opción ‘Work Offline’ del menú Plastic
SCM.

Nota: Note que no todas las opciones de Plastic SCM están disponibles en el
modo de trabajo fuera de línea; sobre todo aquellas que tienen que ver con el
servidor, como ‘update’.

Nota: No se permite mover o renombrar directorios en el modo fuera de línea.

135
 Manual de Usuario

14. Sistema de consultas

Plastic SCM proporciona un mecanismo de consultas e informes que ofrece la

base para implementar una amplia variedad de estadísticas sobre el desarrollo.
Se trata de un mecanismo de consultas simplificado, que permite recuperar
información de los objetos del repositorio pudiendo especificar una amplia
variedad de filtros y sus combinaciones.
A través del sistema de consultas, Plastic SCM puede responder a preguntas
como:
• ¿Qué ítems están en la etiqueta xx y no están en la etiqueta yy? (o lo que
es lo mismo ¿qué ha cambiado entre estas dos etiquetas?)
• ¿Qué revisiones ha creado el usuario ‘xx’ en la rama ‘rr’ en la última
semana?
• ¿Qué revisiones hay en el changeset xx?
Adicionalmente es posible exportar cualquier consulta en formato XML, gracias a
lo que se abren numerosas vías de integración con herramientas de terceros.

14.1. Lenguaje de consulta

Plastic SCM ofrece un lenguaje propio de consultas para especificar el tipo de
objetos a devolver como resultado, y los parámetros de filtrado de esos objetos.
Todas las consultas ocurren a través del comando ‘find’.

cm find objeto [where condiciones] [on repositories repositorios]

Los tipos de objeto posibles son:

136
 Manual de Usuario

Attribute

Attributetype

Branch

Changeset

Link

Linktype

Marker

Merge

Moved

Removed

Revision

User

Wkrepository

Workspace

Las consultas solo pueden realizarse sobre un tipo de objeto a la vez, aunque sí
es posible realizar esa búsqueda sobre diferentes repositorios simultáneamente.
Las condiciones de la consulta se especifican a través de la cláusula where. Es
posible agrupar varias condiciones a través de los operadores and y or, y es
obligatorio encerrar los valores de cadena entre comillas simples cuando se
utilizan para especificar filtros. Por ejemplo, obtener todas las revisiones que se
encuentran en la rama ‘/main/child1’:

cm find “revision where branch = ’br:/main/child1’”

Cada entidad posee una serie de atributos que pueden emplearse para
especificar las condiciones de filtrado, así como el formato de salida.
Los siguientes atributos son comunes para todas las entidades del sistema, con
la excepción de los tipos user, wkrepository y workspace:

Id: Identificador único del objeto.

Owner: Nombre del usuario que creó el objeto.
Date: Fecha en que se creó el objeto.
Comment: Comentario asociado a la creación del objeto.

Para cada uno de los objetos se puede especificar el usuario “ME” y la consulta
buscará los objetos creados por el usuario que está en ese momento logeado en
el sistema.
Los siguientes apartados describen los atributos específicos de cada uno de los
tipos de objeto anteriores.

137
 Manual de Usuario

Attribute 
Srcobj: Objeto origen
Type: Tipo de objeto
Value: Valor dado

Attributetype 
Name: Nombre del atributo
Source: Atributos aplicados al objeto
Value: Valor aplicado al objeto, el resultado es el atributo que
contiene ese valor

Branch 
Name: Nombre de la rama
Parent: Especificación de la rama padre
Attribute: Atributo que se le da a la rama
Attrvalue: Valor del atributo que se le da a la rama

Changeset 
Attribute: Atributo que se le da al changeset
Attrvalue: Valor del atributo que se le da al changeset
Changesetid: ID del changeset

Link 
Type: Tipo de links disponibles
Dstobj: Objeto de destino
Srcobj: Objeto origen

Linktype 

Name: Nombre del link

Source: Especificación del objeto origen del link
Destination: Especificación del objeto destino del link

Marker 
Attribute: Atributo dado a la etiqueta
Attrvalue: Valor del atributo dado a la etiqueta
Name: Nombre de la etiqueta
Revision: Especificación de la revisión a la que se aplica la
etiqueta

Merge 
Dstbranch: Especificación de la rama de destino
Dstrev: Especificación de la revisión de destino
Dstchangeset: Changeset de la revisión de destino
Srcbranch: Especificación de la rama origen
Srcrev: Especificación de la revisión origen

138
 Manual de Usuario

Srcchangeset: Changeset de la revision de origen

Moved 
Dstbranch: Especificación de la rama de la revisión de destino
Dstchangeset: Changeset de la revision destino
Dstdirrev: Especificación de la revisión de destino
Item: Especificación del item que fue movido
Itemid: Id del item que fue movido
Srcbranch: Especificación de la rama de la revision de origen
Srcchangeset: Changeset de la revision origen
Srcdirrev: Especificación de la revisión origen

Removed 
Branch: Especificación de la rama en que el item fue borrado.
Changeset: Changeset de la revisión en que el item fue borrado
Dirrev: Especificación de la revisión del directorio en la cual se
borro el item.
Item: Especificación del item que fue borrado
Itemid: Id del item que fue borrado

Revision 
Branch: Especificación de la rama a la que pertenece la revisión.
Changeset: Número de changeset asociado a la revisión.
Item: Especificación del ítem al que pertenece la revisión.
Marker: Nombre de la etiqueta asociada a la revisión.
Parent: Especificación de la revisión padre de la que puede partir
otra revisión.
RevNo: Número de la revisión.
Size: Tamaño en bytes de la revisión.
Label: Nombre de la etiqueta asociada con la revisión
Type: Tipo de la revisión. Puede ser de tipo texto, binaria o
directorio.
Attribute: Atributo dado a la revisión
Attrvalue: Valor del atributo dado a la revisión

User 

Name: Nombre del usuario.

Code: SID de identificación del usuario. Depende del sistema de
autenticación configurado.
Active: Booleano que identifica si el usuario esta activo o no.
Group: Booleano que identifica si corresponde con un grupo de
usuarios.

Wkrepository 
Alias: Alias dado al repositorio
Id: ID del objeto
Name: Nombre dado al repositorio
Owner: Nombre del usuario que creó el repositorio

139
 Manual de Usuario

Repid: ID del repositorio en el servidor de repositorios

Server: Servidor en el cual está localizado el repositorio

Workspace 
Id: ID del objeto
Machine: Máquina en la cual está situado el espacio de trabajo
Name: Nombre dado al espacio de trabajo
Owner: Nombre del usuario que creó el espacio de trabajo
Path: Ruta en la cual está localizado el espacio de trabajo

14.2. Ejemplos de uso

Revisiones de una determinada etiqueta:

cm find “revision where marker=’BL002’”

Revisiones creadas por un usuario en un periodo de tiempo y en la rama

principal:

cm find “revision where owner = ’user’ and date between

’01/01/2007’ and ’02/02/2007’ and branch = ’br:/main’”

Historial de un determinado ítem en una rama concreta:

cm find “revision where item = ’item:.’ and branch =

‘br:/main/task003’”

Revisiones que han cambiado desde la etiqueta ‘excel2’ a la etiqueta ‘excel3’:

cm find “revision where marker = 'excel3' and not marker =

'excel2' --format={item}”

Revisiones binarias de más de 1MB en un changeset concreto:

cm find “revision where type = ’bin’ and size > 1024 and changeset
= 12345”

Revisiones desprotegidas en una serie de ramas:

cm find “revision where revno = ’CO’ and (branch = ’br/main’ or

branch = ’br:/main/task002’)”

Etiquetas que marcan una determina revisión:

cm find “marker where revision = ’.#br:/main#2’”

140
 Manual de Usuario

Ramas hijas de ‘/main’ de un usuario concreto:

cm find “branch where parent = ’br:/main’ and owner = ‘user’”

Usuarios desactivados en varios repositorios:

cm find “user where active=’F’ on repositories ‘rep1’, ‘rep2’”

Ramas integradas por el usuario:

cm find “branches where owner= ’ME’ and attrvalue: ‘Integrated’”

Espacios de trabajo creados por el usuario en su máquina

cm find “workspaces where owner=’ME’ and machine=’mycomputer’”

Ramas marcadas con el atributo que permanecen abiertas:

cm find “branches where attribute=’Status’ and attrvalue=’Open’”

Merges realizados desde la rama ‘/main/task001’ a la rama ‘/main’

cm find “merges where srcbranch=’br:/main/task001’ and

dstbranch=’br:/main’”

Revisiones creadas en ‘/main’ resultado de la integración de cualquier rama en el

changeset 5

cm find “merges where dstbranch=’br:/main and dstchangeset=5’”

Movidos realizados de item ‘doc’ en la rama ‘/main’

cm find “moved where item=’doc’ and (srcbranch=’br:/main’ or

dstbranch=’br:/main’)”

Borrados realizados en la creación de la revision ‘.#br:/main#4’

cm find “removed where dirrev=’.#br:/main#4’”

141
 Manual de Usuario

14.3. La gramática del lenguaje de consultas

142
 Manual de Usuario

15. Sistema de consultas avanzado (AQS)

Además del sistema de consultas, Plastic también proporciona un mecanismo de

consultas avanzado, disponible a través de la interfaz de la línea de comandos de
Plastic, y en particular en el comando cm query, que permite recuperar objetos
de una o varias entidades a la vez en función de unos criterios de búsqueda. Le
permite al usuario realizar cualquier tipo de consulta contra el sistema.

Las diferencias entre los dos sistemas de consultas disponibles es que el simple
va a realizar las consultas directamente sobre las entidades del sistema y solo
sobre una entidad a la vez, mientras que el avanzado lo realiza directamente
sobre las bases de datos del servidor y se puede realizar sobre una o varias
entidades a la vez, por lo que el avanzado nos va a poder proporcionar más
información que el simple, pero para consultas que se puedan hacer con
cualquiera de la dos se recomienda realizarlo con el sistema de consultas simple
porque la consulta a realizar es mucho más sencilla. En el apartado de ejemplos
se puede ver un caso realizado para los dos sistemas de consultas, para
comprobarlo. Aunque hay entidades que son iguales en ambos sistemas, anotar
que hay mayor número de entidades en el AQS y que algunas son distintas.

A través del sistema de consultas, Plastic SCM puede responder a preguntas

como:
• ¿En qué ramas tiene alguna revisión un determinado ítem?
• ¿De qué revisiones se ha hecho merge hacia main desde una fecha dada?

143
 Manual de Usuario

15.1. Lenguaje de consulta

Para realizar las consultas el comando cm query va a utilizar una sintaxis SQL
para realizar las mismas sobre la base de datos del servidor. Se va a hacer uso
de todas las posibilidades de SQL, de tal modo que hasta las funcionalidades
más avanzadas de Plastic van a utilizar AQS.

El AQS está totalmente integrado con Plastic y no impone restricciones

adicionales al funcionamiento del sistema. Funciona sobre todos los sistemas
operativos que soporte PlasticSCM.

Para poder ejecutar una consulta de este tipo el usuario deberá disponer del
permiso advanced query sobre el repositorio.

Las consultas se pueden realizar sobre una entidad o varias a la vez.

El siguiente listado muestra las entidades sobre las que se pueden realizar
consultas:

Items

Revisions

Checkouts

Branches

Labels

LabeledRevisions

Links

LinkedObjects

Attributes

Objectswithatributes

Changesets

Cada entidad posee una serie de atributos que permiten definir los criterios de
búsqueda, y así limitar el número de objetos recuperados de cada entidad. Los
siguientes atributos son comunes para todas las entidades del sistema:

Owner: Nombre del usuario que creó el objeto en el sistema.

CreationDate: Fecha en que se creó el objeto en el sistema.

144
 Manual de Usuario

A continuación se muestran los atributos propios para cada una de las entidades
mencionadas anteriormente.

Items 

Objectid: Identificador del ítem .

Revisions 

Objectid: Identificador de la revisión.

Sizebytes: Tamaño en bytes de la revisión

Itemid: Identificador del ítem del que queremos saber la revisión

Branchid: Identificador de la rama a la que pertenece la revisión

Revisionnumber: Número de revisión

Changeset: Número de changeset asociado a la revisión.

Comment: Campo de comentarios incluido en la revisión

Checkouts 

Revisionid: Especificación del identificador de la revisión a la

que se aplica el checkout

Workspaceserver: Espacio de trabajo del servidor

Clientmachine: Máquina donde está instalado el cliente

Exclusive: te dice si hay checkouts exclusivos

Branches 

Objectid: Identificador de la rama

Name: Nombre de la rama

ParentBranchid: Identificador de la rama padre

Revision: Revisión de la rama

Labels 

Objectid: Identificador de la etiqueta

Name: Nombre de la etiqueta

145
 Manual de Usuario

LabeledRevisions 

Labelid: Identificador de la etiqueta

Revisionid: Identificador de la revisión

Links 

Objectid: Identificador del link.

Name: Nombre del link

Linkedobjects 

Linkid: Identificador del link

Sourceobjectid: Especificación del objeto origen del link

Destinationobjectid: Especificación del objeto destino del link

Attributes 

Objectid: Identificador del atributo.

Name: Nombre del atributo

Objectswithattributes 

Attributeid: Identificador del atributo

Sourceobjectid: Identificador del objeto fuente del atributo

Attributesvalue: Valor de los atributos

Changesets 

Changesetnumber: Número de changeset asociado a la revisión.

Para poder gestionar la resolución de paths y de usuarios en las consultas, se

van a introducir dos funciones de resolución predefinidas. Estas son:

SolvePath(path): La herramienta Plastic va a utilizar unos

identificadores de item para cada objeto que esté en sus
repositorios. Lo que va a hacer esta función es resolver las rutas
de disco a los identificadores de ítem (itemid) que utiliza
Plastic.

146
 Manual de Usuario

SolveUser(nombre_usuario): Resuelve el nombre de usuario dado al

formato que maneja PlasticSCM para identificar al mismo.

Para mostrar el resultado de las consultas de forma legible al usuario, se puede

indicar al intérprete de consultas las siguientes opciones:

--solveuser=nombre_columna: Indica al intérprete de consultas que

la columna especificada contiene usuarios. Se resolverá el
convertir los identificadores de usuario en nombres de usuario

--solvepath=nombre_columna: Indica al intérprete de consultas que

la columna especificada contiene identificadores de item. Se
resolverá el convertir los identificadores de item a rutas de
disco.

--outputfile=ruta: Escribe en un fichero el resultado de la

consulta

--columnwidth=valor: Especifica la anchura de cada columna del

resultado de la consulta.

Se pueden especificar varios nombres de columnas separados por comas.

Para que se entienda para qué sirven tanto las funciones predefinidas como las
opciones de las consultas, y entender por qué es necesario utilizar ambas a la
hora de realizar las consultas, a continuación de muestran varios ejemplos
aclaratorios:
Revisiones del repositorio actual

cm query “SELECT * FROM revisions”

Revisiones del repositorio actual del item cuyo itemid utilizado por Plastic se
corresponda con la ruta especificada c:\workspace. Lo que hace la función es
resolver la ruta de disco especificada al identificador de item utilizado por Plastic
de la misma.

cm query “SELECT * FROM revisions WHERE

itemid=’SolvePath(c:\workspace)’”

Se obtiene lo mismo que lo anterior pero ahora la columna itemid no va a

contener el identificador de item sino la ruta de disco correspondiente a ese
identificador, en el caso del ejemplo, c:\workspace.

cm query “SELECT * FROM revisions WHERE

itemid=’SolvePath(c:\workspace)’” -–solvepath=itemid

Revisiones del repositorio actual del item cuyo identificador de usuario utilizado
por Plastic se corresponde con el usuario especificado a la función.

cm query “SELECT * FROM revisions WHERE owner=’SolveUser(dave)’”

147
 Manual de Usuario

So obtiene lo mismo que lo anterior pero ahora la columna owner no va a

contener el identificador de usuario utilizado por Plastic sino el nombre de
usuario.

cm query “SELECT * FROM revisions WHERE owner=’SolveUser(dave)’” -

–solveuser=owner

15.2. Ejemplos de uso

Checkouts del repositorio

cm query “SELECT * FROM checkouts

Ramas del repositorio actual creadas por el usuario especificado.

cm query “SELECT * FROM revisions WHERE owner=´SolveUser(dave)’ ”

En qué ramas que tienen alguna revisión el item c:\workspace\file.txt

cm SELECT DISTINCT r.ITEMID as path, b.NAME

FROM REVISIONS r,BRANCHES b

WHERE r.BRANCHID=b.OBJECTID
AND
r.ITEMID=SolvePath(c:\workspace\file.txt)

ORDER BY r.OBJECTID"

--solvepath=path --columnwidth=50

De qué revisiones se ha hecho merge hacia main desde una fecha dada

cm query "SELECT BR1.NAME, R1.ITEMID

from REVISIONS R1, REVISIONS R2, BRANCHES BR1, BRANCHES BR2,

LINKEDOBJECTS LO, LINKS L

where LO.SOURCEOBJECTID = R1.OBJECTID

and R1.BRANCHID = BR1.OBJECTID

and LO.DESTINATIONOBJECTID = R2.OBJECTID

and L.OBJECTID = LO.LINKID

and R2.BRANCHID = BR2.OBJECTID

AND BR2.Name='main'

AND L.NAME='merge'

148
 Manual de Usuario

AND R2.CREATIONDATE > '2007/07/15'"

--SolvePath=ITEMID --columnwidth=30

149
 Manual de Usuario

16. Importar desde otros SCM

16.1. Introducción
Plastic SCM ofrece la posibilidad de importar repositorios desde otros sistemas
de control de versiones. Si bien el importador trata de reconciliar tanta
información como es posible, debido a la forma de almacenar los datos de cada
sistema particular el proceso de importación no da lugar a una réplica exacta del
repositorio original, sino más bien a una adaptación del antiguo sistema al
formato de Plastic SCM.

16.2. Modo de funcionamiento

El proceso de importación requiere seguir una serie de pasos en secuencia.
Algunos de esos pasos son comunes a todos los proveedores de control de
código fuente y otros son específicos.
Para llevar a cabo la importación de un repositorio desde otro sistema de control
de versiones se puede emplear el Asistente de Importación, que guiará al
usuario de manera gráfica por las diferentes opciones disponibles en los
diferentes controles de código o se puede emplear el importador en línea de
comandos, que ofrece la misma funcionalidad y resultará más apropiado desde
el punto de vista de la automatización.

16.2.1. Pasos previos

Antes de comenzar la importación es necesario que el cliente tenga configurado
el servidor de espacios de trabajo apuntando al servidor en el cual desea realizar
la importación, además este debe encontrarse arrancado.
También es necesario que el servidor tenga creado el repositorio que será
destino de la importación.

150
 Manual de Usuario

16.2.2. Ejecución
Para lanzar una importación se hace uso del ejecutable climporter.exe que se
encuentra en la carpeta donde se instalo el cliente. Se trata de un programa de
línea de comandos, que únicamente necesita como argumento el modulo o
proyecto que se desea importar.
Además acepta como opción el parámetro --restore. Este sólo tiene sentido
cuando en un intento de importación anterior, se llego a generar el fichero de
históricos correctamente (ya que si no tendría que recomenzar desde el
principio). El nombre de este fichero es el del proyecto que se desea importar
con la extensión .dat.
Esta opción resulta muy útil cuando la importación abortó debido a una falta de
compatibilidad entre los usuarios de las revisiones de origen y los usuarios de
Plastic SCM, ya que bastaría con mapear estos usuarios correctamente y
continuar la importación desde ese punto.

16.2.3. Usuarios
Plastic SCM utiliza un modo de autenticación de usuarios integrado con el del
sistema en que está implantado, bien sea por LDAP, Active Directory o usuarios
locales, pero en cualquier caso el sistema no dispone de usuarios propios.
Visto esto, es fácil ver que para importar los propietarios de las revisiones del
control de versiones origen, es necesario que estuvieran creados en el sistema
destino que se emplea para la autenticación, lo cual sería tarea del administrador
de sistemas.
Para solventar este problema se permite realizar un mapeo de usuarios, es decir,
se puede especificar a qué usuario de Plastic SCM se corresponde cada usuario
que se desea importar. Esto se hace mediante el fichero users.conf, que tiene la
siguiente estructura:

<ImportUsers>
<MappedUsers>
<MappedUser>
<Source>usr1</Source>
<Plastic>PlasticUsr1</Plastic>
</MappedUser>
<MappedUser>
<Source>usr2</Source>
<Plastic> PlasticUsr2</Plastic>
</MappedUser>
</MappedUsers>
</ImportUsers>

Se tiene una entrada MappedUser por cada usuario que se desee mapear. En
caso de que fuera necesario podrían mapearse varios usuarios a un mismo
usuario reconocido por Plastic SCM.
El mapeo de varios usuarios sobre uno mismo puede ser bastante útil en caso de
que el sistema origen tuviera revisiones de más usuarios que los que permite la
licencia del servidor de Plastic SCM, en ese caso para llevar a cabo la
importación se vería obligado a mapear varios usuarios a uno mismo de modo
que el servidor de Plastic SCM sólo registrara tantos usuarios como permite su
licencia.

151
 Manual de Usuario

16.2.4. Mecanismo de importación

El importador hace uso de un archivo de configuración import.conf. Este tiene
algunas claves comunes para cualquier importación y otras propias del
proveedor de importación que se use.
Su estructura mostrando sólo las claves comunes sería (a estas habría que
añadir las particulares de cada proveedor que se explican más adelante):

<ImportConfig>
<ProviderName>cvs</ProviderName>
<WorkspacePath>./wksimport</WorkspacePath>
<WorkspaceName>wksimport</WorkspaceName>
<PlasticRepository>default</PlasticRepository>
</ImportConfig>

El significado de cada clave es el siguiente:

• ProviderName: Especifica el proveedor utilizado para realizar la
importación, es decir de qué control de versiones se quiere importar. De
momento es soportado cvs y vss.
• WorkspacePath: Ruta del sistema de ficheros que se empleara como
espacio de trabajo para realizar la importación, puede ser tanto una ruta
absoluta, como relativa.
• WorkspaceName: Nombre que se dará al espacio de trabajo utilizado para
la importación.
• PlasticRepository: Especifica el repositorio del servidor Plastic SCM sobre
el que llevará a cabo la importación.
Para llevar a cabo la migración el importador realiza las siguientes acciones:
• Creación del espacio de trabajo para la importación.
• Obtención del proyecto que se desea importar.
• Obtención del histórico de todos los ítems a importar. Una vez terminado
este proceso se genera el archivo binario NombreProyecto.dat
mencionado anteriormente.
• Procesado de todos los históricos y generación de la estructura adaptada
a Plastic SCM.
• Verificación de usuarios. En este momento puede indicarse la necesidad
de realizar algún mapeo.
• Creación de etiquetas y ramas.
• Importación de la rama principal. En este momento es donde se cargan y
se almacenan todas las revisiones de los ítems pertenecientes a la rama
principal.
• Importación del resto de ramas. Aquí solo se crearían las revisiones de los
elementos pertenecientes a cada rama.
• Etiquetado de revisiones. Una vez creadas todas las revisiones se procede
a etiquetar todas las que sean necesarias.

152
 Manual de Usuario

16.3. Proveedores de importación

16.3.1. Microsoft Visual SourceSafe

Requisitos previos 
Antes de realizar una importación de un proyecto en Visual SourceSafe deden de
tenerse en cuenta los siguientes requisitos:
• El cliente de SourceSafe debe de estar en la ruta.
• El espacio de trabajo que se vaya a utilizar para el proceso de
importación debe de estar vacío.
• El cliente de Plastic SCM debe de estar configurado.
• Asegurarse de que todos los objetos están controlados.
• Asegurarse de que todos los ficheros compartidos están ligados a la
misma versión.
• Si el fichero SRCSAFE.INI está localizado en una carpeta compartida,
asegurarse de que Windows ha creado una conexión de red apuntando a
este recurso.

Parámetros de configuración 
El archivo import.conf para una importación desde Visual SourceSafe tendría la
siguiente forma:

<ImportConfig>
<ProviderName>vss</ProviderName>
<WorkspacePath>./wksimport</WorkspacePath>
<WorkspaceName>wksimport</WorkspaceName>

<RepositoryPathVSS>\\vsserver\repositories\vss</RepositoryPathVSS>
<UserVSS>user</UserVSS>

<PasswordVSS>password</PasswordVSS><PlasticRepository>default</Pla
sticRepository>
</ImportConfig>

Como claves adicionales aparecen:

• RepositoryPathVSS: Ruta donde se encuentra el repositorio de
SourceSafe. Puede ser tanto un directorio local, como una carpeta
compartida. Se corresponde con la variable de entorno SSDIR.
• UserVSS: Usuario con el que se va autenticar contra el repositorio de
SourceSafe. Se corresponde con la variable de entorno SSUSER.
• PasswordVSS: Password correspondiente al usuario utilizado. Se
corresponde con la variable de entorno SSPWD.

Consideraciones 
En Visual SourceSafe no existe el concepto de ramas, de modo que toda la
importación del proyecto se hará en la rama main de nuestro repositorio.

153
 Manual de Usuario

El concepto de share/branch de SourceSafe no tiene correspondencia en Plastic

SCM, luego si existe un ítem con estas características en el repositorio durante la
migración se importarán todas sus revisiones.
Desde este provider se importarán todas las revisiones de todos los ficheros, con
información acerca de su propietario, fecha y comentario asociado. También se
importan todas las etiquetas así como el etiquetado de cada una de las
revisiones.

16.3.2. CVS

Requisitos previos 
Antes de realizar una importación de un proyecto en CVS hay que verificar que
se cumplen los siguientes requisitos previos:
• El cliente de CVS debe de estar en la ruta.
• El espacio de trabajo que se vaya a utilizar para el proceso de
importación debe de estar vacío.
• El cliente de Plastic SCM debe de estar configurado.

Parámetros de configuración 
El archivo import.conf para una importación desde CVS tendría la siguiente
forma:

<ImportConfig>
<ProviderName>cvs</ProviderName>
<WorkspacePath>./wksimport</WorkspacePath>
<WorkspaceName>wksimport</WorkspaceName>

<RepositoryConnectionCVS>:pserver:usr:[email protected]:/cvsroot<
/RepositoryConnectionCVS>
<PlasticRepository>default</PlasticRepository>
</ImportConfig>

Como claves adicionales aparecen:

• RepositoryConnectionCVS: Cadena de conexión para poder establecer
comunicación con el servidor de CVS.

Consideraciones 
El resultado de una importación de CVS a Plastic SCM es muy transparente para
el usuario, es decir cuando el usuario explore el repositorio migrado en Plastic
SCM, verá que tiene las mismas ramas que en CVS, las mismas etiquetas, todos
los datos de cada revisión así como sus correspondientes etiquetados, todas las
revisiones dentro de sus ramas correspondientes, etc.

16.3.3. Subversion

Requisitos previos 
Antes de realizar una importación de un proyecto en Subverion hay que
comprobar ciertos requisitos:
• El cliente de CVS debe de estar en la ruta.
• El espacio de trabajo que se vaya a utilizar para el proceso de
importación debe de estar vacío.

154
 Manual de Usuario

• El cliente de Plastic SCM debe de estar configurado.

• El repositorio en el que se realizará la importación no debe de existir
anteriormente ya que se creará durante el proceso.

Parámetros de configuración 
El archivo import.conf para una importación desde Subversion tendría la
siguiente forma:

<?xml version="1.0"?>
<ImportConfig xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ProviderName>svn</ProviderName>
<WorkspacePath>c:\wksimport\3</WorkspacePath>
<WorkspaceName>wksimport</WorkspaceName>
<RepositoryConnectionCVS />
<RepositoryPathVSS />
<UrlSVN>svn://localhost</UrlSVN>
<TrunkDirSVN>trunk</TrunkDirSVN>
<LabelsDirSVN>tags</LabelsDirSVN>
<BranchesDirSVN>branches</BranchesDirSVN>
<UserVSS />
<PasswordVSS />
<ExportDirectoryVAJ />
<PlasticRepository>svn_project</PlasticRepository>
<LoadRevisions />
</ImportConfig>

Consideraciones 
Dada la arquitectura de Subversion y teniendo en cuenta que para esta
herramienta todo son carpetas y que no distingue entre la rama principal, el
resto de ramas o las etiquetas, sino que su significado depende de su ubicación,
es necesario decir que para que la importación tenga un éxito completo, el
repositorio de SVN debe estar correctamente estructurado.
Se considera un repositorio de SVN con una estructura correcta aquel que tiene
un directorio para la rama principal (generalmente llamado “trunk”), otro para el
resto de ramas (denominado “branches”) y otro para las etiquetas (llamado
“tags”); de modo que no se hayan hecho renombrados de estas carpetas, que no
haya trabajo fuera de estos directorios ni se hayan hecho copias dentro de una
misma rama.
En caso de que no se haya trabajado siguiendo la estructura estándar de
directorios la importación intentará recuperar el mayor número de revisiones
posible, aunque según el caso es posible que se pierda alguna revisión o bien
que aparezca un item con el historial partido en diferentes ítems.

155
 Manual de Usuario

17. Referencias

1. Appleton, B., Berczuk, S., Cabrera, R., Orestein, R.: Streamed Lines:
Branching Patterns for Parallel Software Development. In Proceedings of
the 1998 Pattern Languages of Programs Conference, PLoP’98.
Washington University Technical Report #WUCS-98-25.
http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/. 1998.
2. Berczuck, Steven. Software configuration management patterns: effective
teamwork, practical integration. Addison Wesley. 2002.
3. http://www.codicesoftware.com1

156