único escollo más peligroso:
Una vez que se define un componente, no se puede mover un elemento exterior de este componente (se puede copiar y volver a crearlo en otro lugar, pero que va a perder su historia)
Práctica recomendada más útil:
Comprenda bien la naturaleza de un componente UCM: se trata de coherencia.
Un componente es un conjunto de archivos que:
- evoluciona como una sola unidad,
- se etiqueta (baseline) como un todo,
- está ramificado en su conjunto.
Si puede hacer evoluciones sin tocar otro grupo de archivos, es probable que tenga dos componentes.
Ejemplo de componentes:
- una aplicación (o una parte autónoma de una aplicación)
- una biblioteca técnica
- un conjunto empaquetado de archivo (por liberación)
El Un documento que debe guiarlo para definir componentes es Applicative Architecture (que toma las especificaciones comerciales y funcionales y p proyectarlos en aplicaciones que luego se especificarán en el nivel técnico y se implementarán).
Cuando se definen todos esos componentes, tiene dos enfoques para gestionarlos:
enfoque de sistema (cada componentes se puede escribir en un proyecto UCM): útil para el inicio de un proyecto, pero engorrosos con proyecto heredado: no es necesario poner una línea de base en cada uno de los componentes simplemente porque 3 archivos han cambiado en uno de esos componentes.
enfoque de componentes: uno o dos componentes de escritura, el resto es no sólo como no modificable componente. Este es un enfoque escalable, que le permite definir un proyecto por componente para desarrollar, con una "configuración fija" (es decir, "las otras líneas base", que representa los estados fijos de los componentes no modificables que necesita tener para compilar el modificable. Puede cambiar en cualquier momento esta configuración, es decir, puede volver a establecer una base de referencia de las bases del componente no modificable siempre que lo desee).
Puede definir tantos proyectos y arroyos que desee, lo que le permite visualizar fácilmente la merge workflow.
Recuerde: una corriente representa un esfuerzo de desarrollo.
no llame a un arroyo después de un recurso (como VonC_stream), pero después de una tarea o conjunto de tareas a realizar en esa corriente (como en APP_LCH_R32_Dev: Desarrollo para la liberación 32th de mi menú de aplicaciones)
Nota : UCM es solo algunos metadatos sobre ClearCase: incluso si un grupo de archivos se define como un componente de UCM, nada le impide seguir creando ramas clásicas que no pertenecen a UCM, checkouts o checkins (en vistas que no son de UCM).
¿Existe el peligro de crear demasiados componentes de grano fino o tener demasiadas dependencias entre los componentes?
Sí, es por eso que la Arquitectura Aplicativa es importante. Nuevamente, una vez que se define un componente, no puede mover elementos entre esos componentes.
Otro de los detalles que debe saber acerca de los componentes es su diseño:
myVob
myComponent1
myComponent2
myComponent3
componente A raíz es siempre en el primer nivel por debajo de un VOB.
También puede definir un componente como un todo VOB pero yo no lo recomendaría (la adición de un puesto de estrés VOB en su servidor VOB. La adición de un directorio dentro de un VOB cuestan nada existente)
Esto significa que si usted define algunas bibliotecas técnicas como componentes, no se puede ir como:
myLibs
Apache
ant
xalan
xerces
pero tendrá que hacer:
myLibs
apapche_ant
apache_xalan
apache_xerces
advertencia final: dependencia (la verdadera marca de un sistema de gestión de la configuración)
Una de las ventajas principales de la UCM (o así que pensé en el momento - 2003 -) es la dependencia.
Si A depende de B, y pongo A en mi proyecto, incluirá automáticamente B en el mismo proyecto.
Magia.
Pero está roto.
- Primero, nunca haga la dependencia basada en la raíz (un componente basado en la raíz es un conjunto de archivos).Se romperá en la primera superposición:
A1
B1
B2
Aquí es necesario B2 seguir construyendo A, pero A comienza a partir de A1 basado en B1: B2 overrides B1. Tan pronto como ponga una línea de base en A (A2), se habrá terminado. Ya no podrás cambiar B. A línea base del parásito (llamada A2!?) Se habrá puesto en el componente (no modificable) B debido a la superposición.
- incluyen siempre sus dependencias en un componente sin raíces
ADep1
A1
BDep1
B1
BDep2
B2
Aquí tienen componentes sin raíces ADep y BDep (un componente sin raíces es un componente especial que agrega otra sin raíces o componentes basadas en root)
Aún tiene una anulación, pero esta vez entre los componentes sin raíz.
Eso todavía hará una línea de base de parásitos (en BDep, llamados A2), pero al menos se podrá rebasar BDep2 en otras líneas de base posterior (BDep3, BDep4 ...)
Más información sobre este Incoherences and Inconsistencies of ClearCase UCM, con Rational counter-arguments here (y justo después de eso su publicación, prueba de que sus argumentos no son muy buenos para decir lo menos).
Lea también How to Leverage Clearcase’s features
Solo he completado la respuesta en respuesta a su comentario. – VonC
Acaba de agregar la advertencia de referencia del parásito sobre la dependencia del componente. – VonC