Monotone-Incremento Número de versión basado en Mercurial Commits

Question

Cuando estaba usando subversion para el código de una aplicación, podía agregar un período y el resultado de svnversion al número de versión para crear un número de versión único y monotono y también se garantiza que cualquier salida de la misma revisión del código generará el mismo número de versión.

En Mercurial, debido a que los números de revisión no son necesariamente consistentes entre los clones, el número de revisión local no es adecuado. El hash es apropiadamente único y consistente, pero no crea un número que sea monótona. ¿Cómo puedo generar un número adecuado para agregar al número de versión en función de los commits del repositorio de Mercurial?

edición: Tengo una aplicación que tiene comprobación de actualización automática que depende de un número de versión que es una cadena de números enteros separados por un período para determinar si una versión es más nueva o no. Se ha vuelto común que en el tiempo transcurrido entre lanzamientos, algunos usuarios prueben construcciones de prueba. A menudo, estas construcciones resuelven un problema que el probador estaba teniendo, por lo que el probador deja de usar la versión lanzada y cambia a la versión de prueba. Mis objetivos originales de la adición del componente adicional al número de versión fueron:

• asegurar que cuando llegó la liberación, los usuarios de la compilación de prueba fueron presentados de forma automática con la actualización, así
• poder decir fácilmente si un probador estaba usando la construcción de prueba más reciente

Por ejemplo, la versión 0.5.0 tenía la versión número 0.5.0.410; antes de que se lanzara la versión 0.5.1, existían compilaciones de prueba con los números de versión 0.5.1.411, 0.5.1.420 y 0.5.1.421; luego, la versión 0.5.1 tenía el número de versión 0.5.1.423.

Answer 1

Todavía en necesidad de algo para tratar de mantener el orden y combinación de diferentes versiones en desarrollo, probé por primera vez el uso de la marca de tiempo Unix de la última confirmación:

REV=$(hg tip --template '{date|hgdate}' | cut -f1 -d' ') 

Esto, sin embargo, es molesto larga (10 dígitos) (Y, por supuesto, no se garantiza que sea único, pero en un proyecto en el que soy el único desarrollador, la probabilidad de dos commits en el mismo segundo es esencialmente 0, de hecho, la probabilidad de dos commits dentro de 1 minuto de entre ellos es esencialmente 0.)

Dado que el número de versión "base" (la parte a la que se adjunta este número de revisión) solo cambia inmediatamente después de una publicación etiquetada, lo que he terminado es la cantidad de minutos entre la punta y el último ancestro etiquetada:

HG_LAST_TAG_TIMESTAMP=$(hg log -r "$(hg log -r '.' --template '{latesttag}')" --template "{date|hgdate}\n" | cut -f1 -d' ') 
HG_TIP_TIMESTAMP=$(hg log -r '.' --template "{date|hgdate}\n" | cut -f1 -d' ') 
REV=$((($HG_TIP_TIMESTAMP - $HG_LAST_TAG_TIMESTAMP)/60)) 

( edición: usando tip fue un error, ya que se refiere a la última comprometerse con ninguna rama, utilizando log -r '.' se refiere a la revisión en la que se basa la copia de trabajo.)

Answer 2

Has golpeado la uña en la cabeza. Usando cualquier número de revisión local que aumenta monótonamente puede entrar en conflicto con la naturaleza distribuida. No hay una forma elegante en torno a esta decisión fundamental de diseño.

Answer 3

Como dijo @Matthew, no puede esperarse ninguna comparación entre los números de versión en todos los clones. Sin embargo, si basa su aplicación en un único repositorio y siempre retrocede a ese repositorio central desde cualquier clon, puede confiar en ese único número de versión central, siempre y cuando se quede en una sola rama.

Básicamente, si utiliza Mercurial de una manera que imita a Subversion, es decir, con un solo repositorio central, puede usar el número de versión como marcador en las compilaciones de su aplicación.

Espero que esto ayude.

Answer 4

Esta es la forma en Fog Creek hace la acumulación de versiones usando Mercurial + algunas otras sugerencias: http://kiln.stackexchange.com/questions/2194/best-practice-generating-build-numbers