Numéro de version croissant monotone basé sur Mercurial Commits

Question

soyez assuré que tout retrait de la même révision du code génèrera le même numéro de version.

Dans Mercurial, parce que les numéros de révision ne sont pas nécessairement cohérents entre les clones, le numéro de révision local ne convient pas. Le hachage est unique et cohérent, mais ne crée pas de nombre monotone. Comment puis-je générer un numéro approprié à ajouter au numéro de version en fonction des validations du référentiel Mercurial?

modifier: J'ai une application qui a mise à jour automatique qui dépend la vérification d'un numéro de version qui est une chaîne de nombres entiers séparés de période pour déterminer si oui ou non une version plus récente est ou non. Il est devenu courant que dans le temps entre les versions, certains utilisateurs essaient des versions de test. Souvent, ces builds résolvent un problème rencontré par le testeur, de sorte que le testeur arrête d'utiliser la version validée et passe à la version de test. Mes objectifs initiaux en ajoutant le composant supplémentaire au numéro de version étaient les suivants:

• faire en sorte que lorsque la libération est intervenue, ceux qui utilisent la version d'essai ont été présentés automatiquement la mise à jour et
• être en mesure de dire facilement si un testeur utilisait la version de test la plus récente

Par exemple, la version 0.5.0 avait le numéro de version 0.5.0.410; avant la publication de la version 0.5.1, il existait des versions de test avec les numéros de version 0.5.1.411, 0.5.1.420 et 0.5.1.421; alors, la version 0.5.1 avait le numéro de version 0.5.1.423.

Answer 1

encore besoin de quelque chose pour essayer de maintenir la commande et l'appariement des différentes versions de développement, j'ai d'abord essayé d'utiliser l'horodatage unix de la dernière livraison:

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

Ceci, cependant, est fâcheusement longue (10 chiffres). (Et, bien sûr, il n'est pas garanti d'être unique, mais sur un projet où je suis le seul développeur, la probabilité de deux commits dans la même seconde est essentiellement 0, en fait, la probabilité de deux commits dans 1 minute de Puisque le numéro de version «de base» (la partie à laquelle ce numéro de révision est ajouté) change seulement immédiatement après une version étiquetée, ce que j'ai fini par utiliser est le nombre de minutes entre la pointe et le dernier ancêtre taggées:

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)) 

(modifier: en utilisant tip a été une erreur, car il fait référence à la dernière engage à une branche, en utilisant log -r '.' fait référence à la révision sur laquelle la copie de travail est basée.)

Answer 2

Vous avez presque atteint le sommet de la tête. L'utilisation de numéro de révision locale croissant de façon monotone peut entrer en conflit avec la nature distribuée. Il n'y a pas de manière élégante autour de cette décision de conception fondamentale.

Answer 3

Comme dit @Matthew, vous ne pouvez pas vous attendre à ce que la comparaison entre les numéros de version entre clones ait une quelconque valeur. Cependant, si vous basez votre application autour d'un référentiel unique et que vous revenez toujours à ce référentiel central à partir de n'importe quel clone, vous pouvez vous fier à ce seul numéro de version central tant que vous vous en tenez à une seule branche.Essentiellement, si vous utilisez Mercurial d'une manière qui imite Subversion, c'est-à-dire avec un seul référentiel central, vous pouvez utiliser le numéro de version comme marqueur dans vos versions d'application.

Espérons que cela aide.

Answer 4

Voici comment Fog Creek fait la construction versioning en utilisant Mercurial + quelques autres suggestions: http://kiln.stackexchange.com/questions/2194/best-practice-generating-build-numbers