Selectores en Plastic SCM: Bienvenidos al lado oscuro
Podría haber titulado este post " el viaje más completo a través de los selectores del espacio de trabajo", que sería más correcto pero demasiado aburrido.
Intentaré explicar, paso a paso, como funcionan los componentes principales dentro del servidor de Plastic ya que casi todos los demás conceptos tienen algo que ver con estos componentes.
Lo primero es lo primero: ¿Qué es un selector? Es selector es tan sólo un texto asociado a un espacio de trabajo, cuya única misión es decir al servidor qué se tiene que descargar en un espacio de trabajo y cómo se realizar las desprotecciones. Realmente "selecciona" (por eso se llama selector) un grupo de revisiones de un repositorio para que se descarguen en el espacio de trabajo.
A lo mejor lleváis meses utilizando Plastic y nunca habéis oído hablar de los selectores...si es así, ¿cómo es esto posible? Bueno, los desarrolladores de la GUI de Códice hicieron un buen trabajo al intentar que los selectores sean lo más transparentes posible. Así que, incluso utilizando la versión standard, cada vez que hacéis una operación de "cambiar a rama" o "cambiar a etiqueta", estáis configurando un selector.
Si haces click derecho en el nombre de tu espacio de trabajo saldrá un menú como el de la siguiente figura, y entonces al hacer click en "configurar selector" se verá la configuración del selector.
Un selector típico (el selector por defecto cuando creas tu primer especio de trabajo en Plastic) tiene la siguiente apariencia:
repository "default"
path "/"
branch "/main"
checkout "/main"
Que significa, regla por regla:
repository "default" -> Trabajaré en el repositorio denominado"default"
path "/" -> Aplica las siguientes reglas a todos los ítems cuya ruta coincida con "/" (la raiz, por lo que todos los elementos) dentro del repositorio anterior.
rama "/main" -> Toma la última revisión de la rama "/main" para cada uno de los ítems. ¿Por qué la última? si por defecto no se especifica otra cosa (como una regla de changeset o una etiqueta o un número de revisión), la regla de la rama toma "lo último de la rama".
checkout "/main" -> Que significa: si alguna vez tienes que desproteger algo, por favor hacer la desprotección en la rama principal.
¿Suena complicado? Bueno, vamos a ver cómo funciona paso a paso. Pero primero pensemos un poco en dos conceptos que acabo de incluir: ¿qué es un ítem? y...¿qué es una revisión?
Un ítem representa un fichero o un directorio, pero es muy importante tener en cuenta que realmente no se parece a un elemento real en un sistema de ficheros. Es un poco difícil de entender al principio. Un ítem le dice a Plastic que "algo" existe, pero no da más información a Plastic.
La información real asociada a un item va dentro de las revisiones. Cada item tiene una o más revisiones y las revisiones, como ya sabréis, están dentro de las ramas.
Como programadores podemos pensar en los ítems como "clases" y "revisiones" como sus casos. ¿Está más claro ahora?
Y podéis pensar: vale, y los ítems almacenan los nombres de los ficheros y de los directorios...¡incorrecto! Es un poco más complicado que eso y da mucha más flexibilidad.
Los nombres de los ficheros y de los directorios están almacenados como datos en las revisiones de los directorios. Quiero decir, ¿cuáles son los datos de un fichero en concreto? Bien, esto está claro, le contenido del fichero, ¿verdad? Entonces, ¿cuáles son los datos de un directorio? ¿Los ficheros y directorios que contiene? Así que cuando se crea un ítem, su nombre no esta asociado al propio ítem, sino que se incluye como información dentro del directorio que contiene el fichero o el directorio. Esto es exactamente por lo que hay que desproteger el directorio padre para añadir un fichero o un directorio, como os habréis dado cuenta al utilizar Plastic.
Hay algo muy importante aquí, que es crítico a la hora de hablar de los selectores: la información del directorio contiene los nombres de los ítems que contiene ese directorio, no los nombres de las revisiones. Por lo que un directorio sabe qué ítems contiene, pero no las revisiones exactas, que se decidirán en cada momento según las reglas de un selector concreto.
Veamos un ejemplo sencillo. Al crear un nuevo repositorio en Plastic se crearán los siguientes objetos por defecto: un ítem raíz (ítem especial que es la raíz del directorio del nuevo repositorio, por lo que se le pueden añadir contenidos), una rama principal (la rama "/main", con la que posiblemente estaréis familiarizados) y una revisión del ítem raíz dentro de la rama principal. Esta revisión es la que permite comenzar a trabajar con el repositorio recién creado.
Si configuráis un selector como el que se describe arriba y se actualiza, se descargará el contenido del nuevo repositorio.
Para la resolución del selector Plastic siempre intentará encontrar el ítem raíz de cada repositorio. Todos los repositorios tienen un ítem raíz, si no es así es que ha habido algún problema con el repositorio y el sistema abortará la operación. En el selector anterior el repositorio es "default".
Una vez que el ítem raíz esta localizado intentará localizar una regla que lleve a la ruta actual. La ruta actual es "/" por lo que se puede utilizar la primera regla.
Intentar configurar el siguiente selector para trabajar con el nuevo repositorio y veamos lo que ocurre:
repository "default"
path "/dumb"
branch "/main"
checkout "/main"
Entonces Plastic dará el siguiente mensaje:
No se puede cargar el ítem raís. El selector del espacio de trabajo posiblemente contenga errores
¿Por qué?, Está intentando cargar una revisión del ítem raíz y encuentra que ninguna de las reglas cumple la ruta "/" ya que necesitan que la ruta sea, al menos "/dumb", y no se puede cargar el directorio raíz.
Si utilizamos el selector apropiado (con una regla de ruta "/") plastic será capaz de localizar la regla que le está diciendo: "carga la última revisión en la rama main". Hay tan sólo una revisión en la rama main en este momento, que es la revisión raíz (la primea, la última y la única que existe por el momento para el ítem), así que se cargará.
Entonces Plastic obtendrá los datos de la revisión raíz. Está vacía por lo que el selector está solucionado.
¿Qué ocurre si ahora añadimos un nuevo fichero dentro del espacio de trabajo?. Para hacer esto (la interfaz gráfica lo gestiona automáticamente, pero desde la línea de comandos habría que desproteger manualmente el directorio raíz) el directorio raíz se desprotegerá, se creará una nueva revisión en estado de desprotección y después se creará un nuevo ítem para el nuevo fichero (por ejemplo file01.txt). Se creará una entrada para file01.txt en la revisión desprotegida del directorio raíz apuntando al ítem nuevo. Después se creará una revisión (en estado de desprotección) para file01.txt. Si ahora se protegen tanto el directorio como el fichero, se obtendrá algo como en la siguiente figura.
Hay dos conclusiones interesantes que hay que entender después de haber llegado a este punto: primero. cómo se almacena la información en las revisiones de los directorios, y segundo: cómo un directorio apunta a su contenido por ítem y no por revisión.
Juguemos un poco con Plastic, y creemos un par de revisiones nuevas del fichero file01.txt. Lo hacemos desprotegiendo el fichero, añadiendo más contenido, protegiéndolo, desprotegiéndolo de nuevo y protegiéndolo otra vez.
Tenemos algo como la siguiente figura.
Ahora juguemos un poco con el selector.
Vamos a configurar el siguiente selector a ver qué pasa:
repository "default"
path "/"
branch "/main" revno "0"
checkout "/main"
Una vez que se ha actualizado el espacio de trabajo comprobaremos que...¡está vacío!
¿Dónde ha ido el fichero file01.txt? Fijémonos detenidamente en el selector. Le estamos diciendo: trae la revisión "0" de la rama main de todos los ítems de la ruta "/". Entonces podemos pensar, "vale, pero necesitamos la primera revisión del fichero file01.txt!!". Y esto no es verdad ya que lo primero que hace el selector es resolver el ítem raíz, una vez que está localizado cargará su revisión 0, y si miramos a la figura detenidamente, veremos que la primera revisión del ítem raíz en main está vacía! No hay contenido que descargar y por eso el espacio de trabajo está vacio ahora.
Entonces, ¿cómo se puede cargar la revisión 0 del fichero file01.txt?. Hay varias opciones, veamos la primera.
repository "default"
path "/file01.txt"
br "/main" revno "0"
path "/"
branch "/main"
Se está especificando cómo cargar el fichero file01.txt.
Plastic evalua las reglas de arriba hacia abajo, primero intentará utilizar la primera regla, si encuentra una opción no irá a la segunda para ese ítem. Entonces, ¿cómo funciona para este ejemplo?
plastic localiza el ítem raíz e intenta cargar una revisión. Evalúa la primera regla pero la regla de la ruta no sigue "/", por lo que va a la segunda regla.
La segunda regla dice cómo cargar el ítem raíz por lo que carga la última revisión de main para el ítem, que es la revisión 1.
plastic obtiene el contenido de la revisión 1 de main desde el ítem raíz, que contiene un fichero: file01.txt. Entonces vuelve a la primera regla del selector.
la primera regla coincide con la ruta ya que es el fichero "/file01.txt" por lo que se aplica a la regla de carga, que está diciendo a Plastic que obtenga la revisión 0 de la rama "/main".
no hay otros ítems pendientes, con lo que el selector está cargado
Exploremos una segunda (y algo más compleja) posibilidad:
repository "default"
path "/?"
br "/main" revno "0"
path "/" norecursive
branch "/main"
Estudiamos el selector detalladamente.
Las reglas de ruta entienden ahora dos caracteres diferentes: * y ?. * que quiere decir 0 o más y ? para 1 o más. Así que estamos diciendo a Plastic que para cada ruta que comience con / y contenga al menos un caracter, ir a la primera regla y si no ir a la segunda.
La segunda regla, que es la que carga ahora el ítem raíz, utiliza una nueva palabra: norecursive que significa: utilizar esta regla sólo para rutas que sean exactas a la regla, no para ficheros o directorior "dentro" de la ruta en la regla.
¿Estáis familiarizados con los changesets? Un changeset se parece a un commit atómico y se crea cada vez que se protege uno o varios ficheros o directorios a la vez. Se genera un número de identificación que se asigna a la revisión que se ha protegido a la vez. Este número es el changeset.
Las reglas del selector también se pueden utilizar para trabajar con changesets. Supongamos que queremos cargar las revisiones del changeset "0" que es el creado por defecto con la revisión inicial del directorio raíz, se configuraría un selector como el siguiente:
repository "default"
path "/"
branch "/main" changeset "0"
Especificando diferentes números para pasar a diversos changesets.
Bueno, esto es todo por hoy, en el siguiente capítulo hablaré de las etiquetas y de cómo funcionan con los selectores. Si tenéis alguna duda siempre podéis preguntar...
0 comentarios:
Publicar un comentario