En el formatting de file RCS en un repository de CVS, ¿qué indica xy0.2 como revisión?

Fondo

Estoy tratando de salvar el código de un repository de CVS. Estoy utilizando reposurgeon para el propósito, y he probado las siguientes herramientas para get una secuencia de git-fast-import :

  • cvs-fast-export , que produce errores (supuesta twig cíclica, pero no proporciona detalles)
  • cvs2git seguido de git-fast-export , que maquina las cosas más allá de la comprensión
  • git-cvsimport seguido de git-fast-export , que crea los mejores resultados hasta el momento, pero también termina lanzando cosas en las twigs a las que no pertenecen.

Este repository de CVS se ha ejecutado en una variedad de versiones de CVS y las tags y sucursales se han movido a la fuerza. Sé que esto significa que ya no puedo salvar esas twigs y tags. Pero que así sea.

Sin embargo, tengo media docena de twigs (de muchas más), además de MAIN , que estoy interesado en conservar durante la conversión en una secuencia de git-fast-import . Mi VCS objective no es Git, pero el punto es que el reposurgeon maneja su input de esta manera y también lo hace de esta manera.

Para dar sentido a los artefactos y limpiar la mayor parte de los elementos antiguos (incluidas las revisiones huérfanas) en una etapa de preprocess por medio de rcs -o<rev> (por supuesto en una copy de mi repository;)), Necesito entender cómo funcionan las entrañas del formatting rcsfile .

El análisis es muy rcsfile.py después de modificar el module rcsgrep de rcsgrep . Pero eso aún no me proporciona ninguna información sobre lo que significan los numbers de revisión, especialmente aquellos sin un delta + log correspondiente.

Lo que veo

De acuerdo con la página del manual de files RCS , no debería haber un caso en el que el tercer segmento de una ID de revisión sea 0. Sin embargo, veo exactamente esa condición.

Esto es lo que hice (como un experimento).

  1. En MAIN : commit a file ( 1.1 )
  2. De MAIN : twig a BranchX ( 1.1 )
  3. En BranchX : cambie el file ( 1.1.2.1 )
  4. En BranchX : cambie el file de nuevo ( 1.1.2.2 )
  5. En MAIN : cambie el file ( 1.2 )
  6. En MAIN : labelr el file foobar ( 1.2 )
  7. Desde MAIN : ramificar a BranchX , moviendo la label de la twig ( 1.2 ), huérfanando efectivamente la twig anterior en 1.1.2.x
  8. En BranchX : elimine el file ( 1.2.2.1 )
  9. En MAIN : cambie el file ( 1.3 )
  10. En MAIN : label a la fuerza el file foobar ( 1.3 )
  11. En MAIN : cambie el file ( 1.4 )
  12. En MAIN : labelr el file foobarbaz ( 1.4 )

Como puede ver en la list anterior y también en el file reproducido a continuación, no hay revisión 1.2.0.2 en forma de delta con logging.

Ahora mis preguntas

Si renuevo la revisión xy recientemente (¡no hay cambios de file!), La ID de revisión resultante es xy0.2 . Eso es similar a la misteriosa ID de revisión que estoy viendo y preguntando.

  • ¿El 0 indica que el file no tiene deltas, de modo que tengo que volver a su ancestro para los contenidos reales?
  • ¿O simplemente indica la "raíz" de esa twig, siendo el cuarto segmento la última revisión en esa twig?

¿Alguien puede arrojar luz sobre estas preguntas o apuntar a un material más completo que la página del hombre vinculada arriba?


A continuación se muestra el file RCS completo:

 head 1.4; access; symbols foobarbaz:1.3 foobar:1.4 BranchX:1.2.0.2; locks; strict; comment @# @; 1.4 date 2014.12.11.13.46.46; author username; state Exp; branches; next 1.3; 1.3 date 2014.12.11.13.44.49; author username; state Exp; branches; next 1.2; 1.2 date 2014.12.11.13.39.31; author username; state Exp; branches 1.2.2.1; next 1.1; 1.1 date 2014.12.11.13.31.41; author username; state Exp; branches 1.1.2.1; next ; 1.1.2.1 date 2014.12.11.13.34.36; author username; state Exp; branches; next 1.1.2.2; 1.1.2.2 date 2014.12.11.13.35.08; author username; state Exp; branches; next ; 1.2.2.1 date 2014.12.11.13.42.32; author username; state dead; branches; next ; desc @@ 1.4 log @Change on MAIN @ text @NOTE: this file will be removed! Another change on MAIN@ 1.3 log @Change on MAIN @ text @d3 1 a3 1 ANother change on MAIN@ 1.2 log @Change on MAIN @ text @d3 1 a3 1 File on MAIN will be forcibly tagged X again ... how does this affect the rev ID?@ 1.2.2.1 log @Removing the two files from X @ text @@ 1.1 log @Adding the experiment file @ text @d3 1 a3 1 Introducing file on MAIN@ 1.1.2.1 log @Changing the file on the X branch @ text @d3 1 a3 1 Changing on X branch@ 1.1.2.2 log @Another change on the X branch @ text @d3 1 a3 1 Another change on the X branch@ 

De acuerdo, resulta que la respuesta a esto está enterrada en el código fuente de CVS.

Para empezar, aquí están los files importantes si está mirando el tree fuente de CVS:

  • src/rcs.c
  • src/rcs.h
  • doc/RCSFILES

Además de eso, tiene la página de rcsfile(5) man rcsfile(5) . Y no se olvide de usar grep al máximo (a less que tenga algo más sofisticado a su disposition, eso es).

La esencia:

  • Una revisión de bifurcación está definida por los primeros tres segmentos (o un número impar mayor), es decir, xyz , por ejemplo, 1.1.2 , que es una bifurcación de la revisión 1.1 .
    • El símbolo para dicha twig apuntará a la revisión xy0.z , o 1.1.0.2 . Donde 0 es un valor mágico definido como RCS_MAGIC_BRANCH en el código CVS. Tenga en count que ningún delta tendrá el tercer segmento establecido en 0 , ya que estos son "numbers de revisión virtual".
  • En stock CVS z (el tercer segmento de una revisión de twig, el cuarto de un número de revisión virtual) siempre será un número par igual o mayor que dos
    • assert((z >= 2) && (z % 2 == 0))
  • Una twig número 1 también está reservada para las sucursales de proveedores según el comentario en rcs.h (ver a continuación).
  • Para search una sucursal , simplemente busque en la list de symbols en la sección de administración del file RCS (por ejemplo, mediante rlog -h <file> , si no desea analizarlo) las revisiones que tienen la penúltima segmento establecido en 0 . Es decir, tiene una revisión que coincidiría con la expresión regular (PCRE) (?:\d+\.\d+\.)+0\.\d+ (espero que haya acertado).

De un comentario en rcs.h

CVS reserva todas las twigs pares para su propio uso. Las twigs "mágicas" (ver rcs.c ) están contenidas como numbers de revisión virtual (solo dentro de las tags simbólicas) fuera de RCS_MAGIC_BRANCH , que es 0 . CVS también se reserva la sucursal ".1" para las revisiones de los proveedores. Por lo tanto, si realiza su propia bifurcación, debe limitar su uso a numbers de twigs impares a partir de 3 .

Las funciones interesantes que usan RCS_MAGIC_BRANCH son RCS_tag2rev() y RCS_gettag .

De los comentarios en rcs.c

Opina sobre RCS_magicrev() :

Devuelve una revisión "mágica" como una twig virtual de REV para el file RCS. Una revisión "mágica" es única en el file RCS. Por único, quiero decir que devolvemos una revisión que:

  • tiene una twig de 0 (ver rcs.h RCS_MAGIC_BRANCH )
  • tiene un componente de revisión que no es una twig existente de REV
  • tiene un componente de revisión que no es una revisión mágica existente
  • es una revisión con número par, para evitar conflictos con las sucursales de proveedores. El primer punto es lo que lo hace "mágico".

Como ejemplo, si pasamos en 1.37 como REV , searchemos una twig existente llamada 1.37.2 . Si no existiera, searchíamos una label simbólica existente con una parte numérica igual a 1.37.0.2 . Si eso no existiera, entonces sabemos que la twig 1.37.2 se puede reservar creando una label simbólica con 1.37.0.2 como la parte numérica.

[…]

Nota: Suponemos que REV es una revisión de RCS y no un número de sucursal.

Las respuestas

  • ¿El 0 indica que el file no tiene deltas, de modo que tengo que volver a su ancestro para los contenidos reales?
    • Básicamente sí. Cuando el penúltimo segmento es 0 , el número de revisión es un número de revisión virtual utilizado para hacer una "reserva" para un número de sucursal.
  • ¿O simplemente indica la "raíz" de esa twig, siendo el cuarto segmento la última revisión en esa twig?
    • No, mira arriba.