¿Cómo encontrar la label más reciente para la revisión actual en Git / HG / Bzr?

Actualmente en mi práctica uso el file VERSION para almacenar:

 mayor = 2
 menor = 0
 fix = 1

lo que significa que las fonts para la versión de producto v2.0.1 o más reciente.

Antes de cada publicación, debo comprometer la actualización de este file para que se etiquete con la label name2.0.1 o release-2.0.1 cubra el contenido anterior (¡y no la versión anterior!).

Creo que es posible evitar este trabajo al generar automáticamente el file VERSION desde el script de compilation.

Mire a la historia de rev:

   + - + ----- + ---------------------- + - YY - + ---- + ------ + ------ + - HH ->
   dev |  |  ^ ^ |  |  |  |  |
      |  |  |  |  |  |  vvv
      |  |  |  |  |  |  + - + ------ + - ZZ --- + ->
      |  |  |  |  |  |  b2 |  |  |
      |  |  |  |  |  |  vvv
      |  |  |  |  |  |  t2.0.0 t2.0.1 t2.1.0
      vv |  |  vv
     t0.1.0 + --- + - XX - + - + --- + - + ----- + ------ + ------ + ------ + - ----- + --->
            b1 |  |  |  |  |  |  |  |
                vvvvvvvv
               t1.0.0 t1.0.1 t1.0.2 t1.1.0 t1.2.0 t1.2.1 t1.2.2 t1.2.3

En el punto XX la versión es 1.0.0 , en el punto YY la versión es 1.0.2 , en el punto ZZ la versión es 2.0.1 .

Para el punto HH no sé cómo configurarlo. Creo que debe ser 1.0.2 , porque no fusionamos la twig dev con la twig de publicación b2 .

Yo leo:

   $ hg help revsets

pero no veo cómo puedo encontrar la label más cercana a la revisión dada. Con Git y Bzr tengo less experiencia …

O si esto no es posible, busco arguments. También me gusta escuchar cómo evitar manualmente el file VERSIÓN si es posible (o los arguments por los que esto no es posible).

PD. Archivo VERSIÓN necesario para mantener la dependencia del package e identificar el estado de origen del producto en los comentarios de los usuarios.

PSS. la label más cercana al término de revisión dado puede parecer algo borrosa, pero cada desarrollador puede decir en qué versión del producto funciona. ¿Por qué esto no puede hacer la máquina?

Podrías usar algo como esto:

hg log --template "{latesttag}-{latesttagdistance}-{node|short}\n" --rev <REV> 

Lo cual devuelve una cadena como:

2.1.4-2-12eeab7a8073

Esto nos dice que:

  • La label más reciente antes de esta confirmación fue 2.1.4
  • La revisión actual es 2 commits pasada esa label
  • El id del set de cambios es 12eeab7a8073

Lea sobre templates para más información.

Git tiene un command de describe incorporado que proporciona la misma información. Sin embargo, debe comprender que, de manera pnetworkingeterminada, solo funciona con tags anotadas (consulte la página de manual para get más información).

bzr tags --sort=time | tail -n1 | cut -d ' ' -f1

Adaptado de la respuesta de dOxxx. Vi que las tags normalmente están orderadas por nombre, pero se puede orderar por time con un argumento.

Incluso puede crear un alias bzr externo utilizando el complemento extcommand. bzr branch http://bzr.oxygene.sk/bzr-plugins/extcommand/ ~/.bazaar/plugins

Luego puede agregar lo siguiente a ~/.bazaar/bazaar.conf

 [EXTERNAL_ALIASES] last-tag = bzr tags --sort=time | tail -n1 | cut -d ' ' -f1 

Entonces puedes hacer:

 $bzr last-tag v0.9.0-SNAPSHOT 

¿Has mirado a git describe para git? Mostrará la label más reciente accesible desde una confirmación.

Git tiene un command que está diseñado exactamente para esto: git-describe . Exactamente cómo usarlo depende de sus necesidades, pero en general, git describe [opts] <commit> produce algo de la forma <tag>-<n-commits>-<short-hash> , diciéndole la label más reciente, cuántos commits se han realizado desde entonces, y un hash abreviado del commit. Por ejemplo, podría darle v1.7.8-rc0-32-g87bf9a7 .

Opciones relevantes:

  • --tags – incluyen todas las tags, no solo las anotadas. Probablemente quieras esto.
  • --match <pattern> – incluye solo tags que coincidan con el patrón dado, por lo que puedes limitarte a tags de versión y no a nada extraño.
  • --abrev=<n> – use n dígitos del hash (configurado en 0 para suprimirlo)

y muchos más – vea la página de manual.

Con respecto a su file VERSION: generalmente no debe rastrearlo. Tener que realizar modificaciones es contraproducente; la confirmación contiene el file, por lo que la versión se modifica (ligeramente) cuando la modifica y la confirma. En su lugar, puede generarlo automáticamente como parte de su process de compilation / implementación, e includelo también en las distribuciones fuente. Puedes search en la fuente de Git un buen ejemplo de esto: hay un script llamado GIT-VERSION-GEN que es invocado por el Makefile, y es esencialmente un contenedor de luz alnetworkingedor de git-describe. Crea un file de versión, que luego se empaqueta en tarballs fuente, y cuyos contenidos son utilizados por el rest del process de compilation para hornear el número de versión durante la compilation.

bzr tags enumeran las tags (y sus revisiones correspondientes) en la twig actual. Creo que la label más reciente aparece primero, por lo que probablemente puedas hacer algo como esto:

 bzr tags | head -n1 | cut -d ' ' -f1