Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Userguide
Userguide
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
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
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
cm help
cm help command
2
Manual de Usuario
1. Introducción
3
Manual de Usuario
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
5
Manual de Usuario
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.
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.
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.
8
Manual de Usuario
item hello.cpp
9
Manual de Usuario
10
Manual de Usuario
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 12: El árbol de versiones del ítem hello.cpp calculado por Plastic
SCM
12
Manual de Usuario
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:
13
Manual de Usuario
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
15
Manual de Usuario
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.
17
Manual de Usuario
18
Manual de Usuario
cm help
cm help comando
cm comando --help
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á.
Desde la línea de comandos
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á.
Desde la línea de comandos
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
Este es un ejemplo del fichero ignore.conf file (El carácter # indica comentario):
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):
21
Manual de Usuario
#Examples:
.java:txt
.cpp:txt
.jpg:bin
.psd:bin
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 *
cm add 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”
23
Manual de Usuario
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’.
24
Manual de Usuario
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
cm ci –R *
cm ci --nchk ítem_desprotegido
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
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’.
cm update –-forced .
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
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.
28
Manual de Usuario
29
Manual de Usuario
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
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
cm co –R directorio/*
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.
31
Manual de Usuario
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.
32
Manual de Usuario
Desde la interfaz gráfica
Desde la línea de comandos
Mostrar los ítems desprotegidos del espacio de trabajo actual
cm findcheckouts
cm fco
cm fco --all
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”.
33
Manual de Usuario
Desde la interfaz gráfica
Cancelando desprotecciones desde la línea de comandos
Cancelar la desprotección de un ítem cualquiera:
cm unco nombre_del_ítem
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.
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”:
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.
35
Manual de Usuario
36
Manual de Usuario
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:
37
Manual de Usuario
38
Manual de Usuario
39
Manual de Usuario
40
Manual de Usuario
41
Manual de Usuario
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 .
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
cm mb --merge br:/main/child1
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
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:
44
Manual de Usuario
Rama /main
0
1
rama001
2 merge
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 rev:test#br:/main/fix#15 --
ancestor=rev:test#br:/main/fix#5 --merge
Desde la interfaz gráfica
Desde el menú de etiqueta: Crear Nueva Etiqueta.
46
Manual de Usuario
Desde la línea de comandos
Para crear una etiqueta se emplea el comando mklabel:
cm mklabel rel1.0
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 –R *
47
Manual de Usuario
Desde la interfaz gráfica
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.
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
Desde la línea de comandos
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
Desde la línea de comandos
Desde la interfaz gráfica
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
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
54
Manual de Usuario
Desde la interfaz gráfica
1. Botón “Obtener” en la barra de herramientas.
Desde la línea de comandos
cm update .
55
Manual de Usuario
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
cm co –R directorio/*
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.
56
Manual de Usuario
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’.
Desde la interfaz gráfica
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.
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.
60
Manual de Usuario
61
Manual de Usuario
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.
62
Manual de Usuario
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.
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"
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
path#label name
/src/main.java#br:/main#23
/src/main.java#lb:RELEASE001
65
Manual de Usuario
br:branch_name
Ejemplos:
br:/main
br:/main/release00
item:path
Ejemplo:
item:/src/hello.java
lb:label_name
Ejemplo:
lb:LABEL001
rep:repository_name@repository_server
Ejemplo:
rep:myrep@REPSERVER:8084
66
Manual de Usuario
wk:workspace_name@client_machine
Ejemplo:
wk:integrator_wk@releaseserver
repserver:servername:portnumber
Ejemplo:
repserver:mainRepServer:8084
wkserver:servername:portnumber
Ejemplo:
wkserver:WorkspaceServer:8084
67
Manual de Usuario
7. Interfaz gráfica
68
Manual de Usuario
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
70
Manual de Usuario
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
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
72
Manual de Usuario
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
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
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
Explorador de ítems
Especificación de la revisión
Explorador de revisiones
75
Manual de Usuario
76
Manual de Usuario
77
Manual de Usuario
Explorador de ramas
Explorador de etiquetas
Tipo de conflicto
Mostrar/Esconder Opciones
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
79
Manual de Usuario
80
Manual de Usuario
81
Manual de Usuario
82
Manual de Usuario
83
Manual de Usuario
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"
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"
repository "default"
path "/"
br "/main"
co "/main"
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"
repository "default"
path "/"
branchpertask “/main/taskXXX” baseline “BL101”
repository "default"
path "/"
br "/main"
co "/main"
86
Manual de Usuario
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.
87
Manual de Usuario
88
Manual de Usuario
89
Manual de Usuario
90
Manual de Usuario
91
Manual de Usuario
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.
C:\wks
C:\wks\project
C:\wks\project\src\...
92
Manual de Usuario
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
Una vez añadidos, los ítems permanecen desprotegidos, como denota el tick gris
que aparece al lado de cada uno de ellos:
94
Manual de Usuario
Ahora el proyecto está listo para ser usado por varios desarrolladores.
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.
95
Manual de Usuario
96
Manual de Usuario
97
Manual de Usuario
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.
98
Manual de Usuario
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.
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
100
Manual de Usuario
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.
102
Manual de Usuario
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.
103
Manual de Usuario
104
Manual de Usuario
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
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:
107
Manual de Usuario
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.
108
Manual de Usuario
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.
110
Manual de Usuario
111
Manual de Usuario
112
Manual de Usuario
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.
114
Manual de Usuario
Manual de
Usuario
115
Manual de Usuario
116
Manual de Usuario
117
Manual de Usuario
• 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
119
Manual de Usuario
120
Manual de Usuario
121
Manual de Usuario
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.
122
Manual de Usuario
123
Manual de Usuario
124
Manual de Usuario
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.
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á.
127
Manual de Usuario
Manual de
Usuario
128
Manual de Usuario
129
Manual de Usuario
130
Manual de Usuario
131
Manual de Usuario
132
Manual de Usuario
133
Manual de Usuario
134
Manual de Usuario
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’.
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’.
135
Manual de Usuario
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’:
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:
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
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
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
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
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
cm find “revision where type = ’bin’ and size > 1024 and changeset
= 12345”
140
Manual de Usuario
141
Manual de Usuario
142
Manual de Usuario
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.
143
Manual de Usuario
Para poder ejecutar una consulta de este tipo el usuario deberá disponer del
permiso advanced query sobre el repositorio.
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:
144
Manual de Usuario
A continuación se muestran los atributos propios para cada una de las entidades
mencionadas anteriormente.
Items
Revisions
Checkouts
Branches
Labels
145
Manual de Usuario
LabeledRevisions
Links
Linkedobjects
Attributes
Objectswithattributes
Changesets
146
Manual de Usuario
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.
Revisiones del repositorio actual del item cuyo identificador de usuario utilizado
por Plastic se corresponde con el usuario especificado a la función.
147
Manual de Usuario
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
AND BR2.Name='main'
AND L.NAME='merge'
148
Manual de Usuario
--SolvePath=ITEMID --columnwidth=30
149
Manual de Usuario
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.
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
<ImportConfig>
<ProviderName>cvs</ProviderName>
<WorkspacePath>./wksimport</WorkspacePath>
<WorkspaceName>wksimport</WorkspaceName>
<PlasticRepository>default</PlasticRepository>
</ImportConfig>
152
Manual de Usuario
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>
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
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>
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
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