Volvemos a ser noticia

12:28 0 Comments


En esta ocasión ha sido la revista "Parques Tecnológicos de Castilla y León" la que se ha hecho eco de la noticia del premio que nos otorgó la revista Castilla y León Económica, con el patrocinio de ForoBurgos, ha en reconocimiento a las mejores iniciativas del tejido empresarial de Castilla y León. Códice Software y otras seis empresas de la región (Inzamac, Dibaq, Hermi, Siro, Postquam y BMC Maderas) fueron seleccionadas entre 90 candidaturas enviadas por un total de 54 empresas.Según el jurado, compuesto por representantes de la Administración regional y el mundo de la empresa, el galardón correspondiente a Producto mas Innovador ha recaido en Plastic SCM, como producto que aporta valor añadido y que ha sido acogido con éxito por el mercado.

Podéis ver la noticia en pinchando aquí.

0 comentarios:

La ruptura, decepción con Clearcase

15:37 0 Comments

Esta es la historia real de una ruptura: un responsable de gestión de la configuración nos cuenta el motivo por el que finalmente terminó con su querido sistema: Clearcase.Probablemente suene chistoso, pero por favor sigan leyendo detenidamente y encontrarán los hechos detrás de esta decepción...Esto es lo ocurrido según nuestro cliente:


Después de 12 trabajando y jugando con clearcase, ¡ya estoy harto!.La preciosa dama de la que me enamoré después de unos pocos meses en una empresa desarrollo de software e I+D se ha convertido en una pesadilla. Y una nueva suegra, IBM, no hizo que las cosas fuesen más fáciles.
En el momento en el que nos conocímos estábamos haciendo desarrollo para medios digitales en sistemas de Silicon graphics.En aquel momento el sistema que tenía en el trabajo era mucho más potente, y mucho más caro que el PC 486 con alguna versión de DOS que tenía en casa. Así que iba a trabajar con la idea de que lo que yo hacía era realmente importante para la empresa. Después de todo, esto fué antes de la burbuja del sector….


Lo que realmente me gustaba de clearcase era el hecho de que era completamente invisible para el desarrollador.




Se configura una vista y se puede empezar a trabajar con cualquier herramienta, las fuentes estaban ahí cuando se necesitaban. Era un entorno rápido y avanzado. Con versionado de directorios, así que se podía cambiar la estructura del código sin problema. Ofrecía un avanzado sistema de ramas y de integraciones, con seguimiento de las integraciones, y la estrategía de ramificación que utilizábamos en ese momento era la de rama por tarea. Era posible hacer esto de manera eficiente con clearcase ya que era realmente bueno en manejo de ramas e integraciones.

¡Y tenía todo esto hace 12 años!

Y el hecho asombroso es que mientras que el resto del mundo ha ido evolucionando clearcase ha escogido la dirección errónea.

Hizo un intento con la implementación más fea jamás concevida para un entorno de gestión de la configuración, UCM (Gestión del Cambio Unificado), intentando imponer un proceso que aumentaba la carga de trabajo de manera absurda encima de la base anterior. Se olvidó completamente de su antiguo amor, el desarrollador, intentando impresionar a aquellos que odiaban el desarrollo. Rompió con la idea de "rama por tarea".


Dejo de tener una interfaz de usuario consistente en todas las plataformas que soporta, utilizando clearcase de diferente manera para UNIX, Microsoft windows o Linux, lo cual cambia bastante. La interfaz gráfica de clearcase para UNIX y Linux es realmente mala. ¿Y por qué tiene la línea de comandos tantas características en comparación con el cliente gráfico? ¿Y por qué se ignora a Apple?

El hecho de que no haya una manera estándar de hacer una protección o desprotección recursiva, los mensajes de error que parecen no tener nada que ver con el error real, el hecho de que si se cambian los finales de línea en los ficheros de texto de un entorno multiplataforma y las herramientas de integración y comparación que dan errores, el hecho de que un número de caracteres en una línea, por ejemplo, en un fichero XML, está limitado y hace que la integración falle...estas son las cosas que podía aguantar.

Pero el verdadero obstáculo viene con las integraciones con otras herramientas como eclipse, WSAD, Visual studio, etc... , estas integraciones son de hecho tan sólo integraciones que permiten hacer protecciones y desprotecciones, cualquier otra operación de clearcase es complicadísima en estos entornos. Simplemente el cambiar de vistas en un entorno de desarrollo a una vista en otra rama en el mismo proyecto es casi imposible, haciendo que la potencia de la estructura de ramas sea inútil.

Mientras que en los viejos tiempos clearcase era invisible para el desarrollador, un compañero silencioso y servicial, ahora hace que el trabajo del desarrollador sea dificil, lento y engorroso. Algunos incluso dicen que volver a la edad de piedra de las prácticas de gestión de la configuración utilizando herramientas como CVS o Subversion, es mejor que utilizar clearcase.

Y justo en el momento en el que necesitaba sentirme joven de nuevo, y encantado con el desarrollo de software, un producto bonito, jóven y libre apareció en escena, creado por desarrolladores para desarrolladores, se centra de nuevo en cómo se puede hacer el desarrollo y las integraciones de manera eficiente, rápida y potente. Con una apariencia consistente en todas las plataformas que soporta. (incluso funciona en Apple, a quien ClearCase siempre ignoró), con un entorno de creación de ramas y de integración, con buenas integraciones con entornos de desarrollo, por lo que el cambiar los espacios de trabajo a otra rama es una tarea muy rápida y fácil, con seguimiento de integraciones y un correcto versionado de directorios.
De hecho, con todo lo bueno de clearcase y una solución para la mayor parte de los problemas que tiene.

Por favor, echen un vistazo a Plastic SCM 2.0 lo antes posible, ¡no os defraudará!

0 comentarios:

Obtener informes sobre la actividad de los repositorios

12:36 0 Comments

¿Qué pasa si quiere saber qué revisiones se han creado en los últimos días? ¿Quién hizo los cambios y dónde? O, ¿si está buscando los cambios que se han realizado en un componente para localizar una modificación específica que le gustaría comprobar?

Ahora esto es muy fácil a través de las vistas personalizables de Plastic 2.0.

Mire la siguiente figura (click para agrandar):




He customizado la vista de changesets para que muestre revisiones. Y estoy utilizando el sistema de consultas para obtener las revisiones que he creado desde el día 1 de Abril en nuestro repositorio principal.

Entonces utilizo el filtro para centrarme en las revisiones del directorio 01nerva

Esta consulta es muy sencilla:

find revisions where date >= '4/1/2008' and owner = 'pablo' on repository 'codice'

Claro que podría ir incluso más allá e intentar centrarme en las revisiones creadas en una rama en concreto, o más que las de un changeset concreto, etc...

La siguiente consulta localizará las revisiones creadas en dos repositorios después de una fecha dada en una rama diferente de la rama principal o main.

find revisions where date >= '4/1/2008' and owner = 'pablo' and branch != '/main' on repositories 'codice','pnunit'

Como se puede ver, el sistema de consultas es muy útil para crear informes de actividad, localizar determinados cambios, inspeccionar modificaciones, etc.

¡Espero que os ayude!

0 comentarios:

Selectores en Plastic SCM: Bienvenidos al lado oscuro II

10:03 0 Comments

¡Bienvenidos de nuevo al lado oscuro de Plastic! Hoy nos vamos a adentrar más en conceptos de ramas e intentaremos explicar como funcionan las ramas y las etiquetas.

En el post anterior introduje diversos conceptos importantes tales como que plastic evalua una por una las reglas del selector, de arriba hacia abajo, y cómo funciona el especificador de la ruta.

Veamos ahora el modificador de la regla del selector de etiquetas. Pero antes de nada, ¿qué es una etiqueta?

Una etiqueta es simplement un objeto dentro de un repositorio de Plastic. Tan sólo eso. Al crear una etiqueta desde la línea de comandos o desde la interfaz gráfica simplemente se crea un nuevo objeto dentro del repositorio.

Las etiquetas son muy útiles una vez que se aplican a las revisiones como se puede ver en el siguiente árbol de versiones. En el árbol se puede ver que la revisión 20 tiene sólo una etiqueta, BL051, pero la revisión 19 tiene muchas (lo cual en este ejemplo significa que pertenece a diversas líneas base...no se ha cambiado en bastante tiempo).





Así que para etiquetar una revisión en Plastic primero hay que tener una etiqueta y entonces aplicar la etiqueta a la revisión. Desde la interfaz gráfica la única opción disponible es etiquetar todo el contenido del espacio de trabajo, lo que significa aplicar la etiqueta a las revisiones que están cargadas en ese momento. ¿Por qué? Porque los usuarios normalmente utilizan etiquetas para agrupar un conjunto de revisiones en momentos específicos como puede ser el caso de sacar una nueva versión. Y normalmente lo que se desea etiqueta es todo el espacio de trabajo.
Veamos el ejemplo de la siguiente figura.



Se puede ver que tenemos un directorio con un par de entradas, una de ellas etiquetada con la etiqueta "BL001". Así que, ¿qué se cargará en el espacio de trabajo si se configura el siguiente selector?


rep "default"
path "/"
label "BL001"



Le estamos diciendo a plastic:
descarga todo lo que esté marcado con BL001. Así que, ¿qué es lo que esperamos que se descargue?

¡Nada!

Obtendremos un error que dirá que no se puede cargar el ítem raíz.

¿Por qué? Bueno, recordemos cómo Plastic resuelve los selectores: primero coge el ítem raíz y busca una revisión utilizando las reglas de los selectores. Así que intentará encontrar una revisión para el ítem raíz etiquetada con BL001 y... si, no puede... se terminó.

Así que, o se etiqueta el ítem raíz también, o se proporciona una regla que cargue la raíz.


rep "default"
path "/"
label "BL001"
path "/"
branch "/main"


Este selector resuelve el problema.Irá a la segunda regla para encontrar la revisión del ítem raíz, con lo que el problema está resuelto.

Ahora entenderéis por qué es tan peligroso el etiquetar revisiones separadas en vez de todo el espacio de trabajo, a no ser que se sepa muy bien lo que se está haciendo.

Las etiquetas son muy útiles ya que proporcionan una gran flexibilidad. En el siguiente ejemplo si se especifica un selector como el anterior se cargará el árbol del espacio de trabajo como el de la parte inferior de la figura.



Entra en el mundo de las ramas
Hasta ahora hemos jugado con revisiones, changesets y ramas. Empecemos a hablar de las ramas.

En plastic una rama es un contenedor de revisiones. Al crear una nueva rama se crea un objeto vacío en un repositorio. Hay que trabajar con ella para darle contenido. Tengan en cuenta que este comportamiento varía del de otros sistemas como Subversion, CVS, SourceSafe, TeamSystem orPerforce, en los que la creación de ramas conlleva copiar las revisiones a la nueva rama.

En plastic, cuando se crea una nueva rama, está totalmente vacía.

¿Cómo se puede utilizar? Supongamos que acabamos de crear una rama main/task001. La creamos desde la línea de comandos:


$ cm mkbr br:/task001


Tener en cuenta que desde la interfaz gráfica normalmente sólo se crean ramas hijas.

Hablaremos de las ramas hijas más adelante.

Bien, ahora tenemos task001, pero, ¿qué podemos hacer con ella?

Ahora ya son casi expertos en selectores, ¿tienen alguna idea?

Qué pasa si configuramos un selector como el siguente:


rep "default"
path "/"
branch "/task001"
co "/task001"


Si, así es...

El servidor dirá que no puede cargar el ítem raíz.

Así que hay que encontrar el modo de que llegue a la rama de la tarea task001...

¿Y la siguiente configuración?


rep "default"
path "/"
branch "/task001"
path "/"
branch "/main"


Bien, funcionará.


Pero estamos cargando las revisiones desde main... ¿Cómo puedo crear una revisión en la nueva rama?


rep "default"
path "/"
branch "/task001"
co "/task001"
path "/"
branch "/main"
co "/task001"

Mirad el selector de arriba. Especialmente la segunda regla.

Está diciendo a plastic: descarga las revisiones de main, pero si hay que desproteger algo... coloca la desprotección en "/task001". Así que, tan pronto como se desprotega un fichero o un directorio... irá a task001, y comenzaremos a utilizar la rama recién creada.

Por favor, tengan en cuenta que si la segunda regla es algo como ruta "/" rama "/main" co "/main" la revisión nunca irá a la tarea task001... así que la primera regla será inútil.

Ahora se ha realizado la primera desprotección en una rama separada... Si se ejecuta un ls desde línea de comandos o si se comprueba la vista de items desde la interfaz gráfica se podrá ver que la revisión está en una rama.

Hay dos cosas importantes aquí:
  • ahora tenemos un mejor entendimiento sobre los selectores
  • ahora entendemos como funcionan las ramas en plastic: este es exactamente el motivo por el que sólo las revisiones cambiadas van a las ramas mientras que el resto se mantienen en la rama padre...

    Ramas y etiquetas combinadas
    Con lo que hemos visto hasta ahora... ¿cómo se implementaría un patrón de rama por tarea?

    Fácil, simplemente se crea una nueva rama para cada nueva tarea, y se configura el selector como el de arriba. ¡Y ya está!

    "Bien" - puedes preguntar - "pero ¿qué pasa si necesito empezar a trabajar desde una línea base específica?".

    Veamos.

    Supongamos que queremos trabajar en la tarea task001, pero el punto de partida debe de ser una línea base estable etiquetada BL059.

    ¿Cómo configuraríamos el selector?

    Recordad: hay que coger todo de la BL059, a no ser que tengamos algo en la rama de la tarea que tengamos que descargar antes...

    Miren el siguiente selector.


    rep "default"
    path "/"
    branch "/task001"
    co "/task001"
    path "/"
    label "BL059"
    co "/task001"

    Bien, ¿no?


    Entonces, ¿para qué son las ramas hijas?

    Si pensáis que no son necesarias... es que sois unos verdaderos hackers del selector. ¡Enhorabuena! :-)

    Volvamos al selector referentes a las ramas /main y /task001


    rep "default"
    path "/"
    branch "/task001"
    co "/task001"
    path "/"
    branch "/main"
    co "/task001"

    ¡Aquí está!


    Después de unas cuantas semanas utilizandolas para seguir el patrón rama por tarea al principio del proyecto (hace mucho, mucho tiempo), obtenemos lo siguiente:

    ¿que pasa si hacemos que /task001 herede de /main de algún modo? Es lo que estamos intentando hacer con el selector...

    ¡Y entonces aparecen las ramas hijas!

    Si se crea la tarea task001 como hija de main, se dice que si la tarea task001 tiene contenido, toma sus revisiones de ella, de otro modo las tomaría de main que es exactamente lo que aparece en el selector anterior.

    Pero las ramas hijas hacen que la vida sea más fácil. Para crear una rama hija se puede ir a la interfaz gráfica o a la línea de comandos y ejecutar


    $ cm mkbr br:/main/task001

    Entonces el selector que se utilizará será:


    rep "default"
    path "/"
    br "/main/task001"
    co "/main/task001"

    ¡Que realmente ahorra dos líneas!.

    Y este es básicamente el motivo por el que las rama hijas aparecieron en escena: para ahorrar líneas al escribir el selector. (En este punto hay que tener en cuenta que cuando se incluyeron las ramas hijas los selectores aún se escribían en formato XML, esto fué en la prehistoria de plastic, antes de que cualquier cliente hubiese oído hablar de nosotros...y el ahorrar unas líneas es muy importante para los desarrolladores perezosos).

    Ramas hijas y etiquetas

    "Bien" - diréis - "pero qué ocurre si quiero utilizar una línea base, que es la manera normal de trabajar de todos modos..."

    ¡Y es cierto!

    Para utilizar una línea base se combina la regla de la etiqueta dentro de la regla de la rama, como en el caso del siguiente selector


    rep "default"
    path "/"
    br "/main/task001" label "BL051;LAST"
    co "/main/task001"


    Para acortar la regla de la etiqueta se puede simplificar:



    rep "default"
    path "/"
    br "/main/task001" label "BL051"
    co "/main/task001"


    Lo bueno es que es muy sencillo escribir selectores para múltiples ramas


    rep "default"
    path "/"
    br "/main/release50/bug-fix490" label "stable040;BL050;LAST"
    co "/main/release50/bug-fix490"

    La regla de rama por tarea

    Y ahora veamos una de las reglas del selector de plastic menos conocidas:


    rep "default"
    path "/"
    branchpertask "/main/task001" baseline "BL009"


    Que equivale a:


    rep "default"
    path "/"
    branch "/main/task001" label "BL009"
    checkout "/main/task001"


    ¡Pero incluso más corto

    ¡En resumen!

    Ahora ya estáis familiarizados con todos los conceptos internos del selector y listos para saltar al siguiente tema: ¡selectores de múltiples repositorios!
  • 0 comentarios:

    Selectores en Plastic SCM: Bienvenidos al lado oscuro

    10:50 0 Comments

    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: