Construire un séquençage lors de l'utilisation du contrôle de version distribué

Question

Nous utilisons actuellement Perforce pour le contrôle de version. Il possède la caractéristique pratique d’un nombre de modifications strictement croissant que nous pouvons utiliser pour faire référence aux générations, par exemple "vous obtiendrez le correctif si votre version est au moins de 44902".

J'aimerais passer à un système distribué (probablement git) pour faciliter la création de branches et le travail à domicile. (Les deux sont parfaitement possibles avec Perforce, mais le workflow git présente certains avantages.) Donc, bien que le "développement des affluents" serait distribué et ne ferait pas référence à un séquencement de révision commun, nous aurions toujours un référentiel git principal dans lequel toutes les modifications devraient être intégrées avant la création d’une compilation.

Quel est le meilleur moyen de conserver des identifiants de construction strictement croissants? La façon la plus simple à laquelle je puisse penser est d’avoir une sorte de hook post-commit qui se déclenche chaque fois que le référentiel maître est mis à jour, et il enregistre (le hachage de) le nouvel objet tree (ou commit)? git) avec une base de données centralisée qui distribue les identifiants. (Je dis "base de données", mais je le ferais probablement avec des balises git et je chercherais simplement le prochain numéro de balise disponible ou quelque chose du genre. La "base de données" serait donc vraiment .git / refs / tags / build-id /.)

Ceci est réalisable, mais je me demande s’il existe une solution plus simple, ou déjà mise en œuvre, ou standard. manière d'accomplir cela.

Answer 1

J'appuie en second lieu la suggestion d'utiliser git décrire . À condition que vous ayez une politique de gestion de version saine et que vous ne fassiez rien de fou avec votre référentiel, git decrire sera toujours monotone (au moins aussi monotone que vous pouvez l'être, lorsque l'historique de vos révisions est un DAG au lieu d’un arbre) et unique.

Une petite démonstration:

git init
git commit --allow-empty -m'Commit One.'
git tag -a -m'Tag One.' 1.2.3
git describe    # => 1.2.3
git commit --allow-empty -m'Commit Two.'
git describe    # => 1.2.3-1-gaac161d
git commit --allow-empty -m'Commit Three.'
git describe    # => 1.2.3-2-g462715d
git tag -a -m'Tag Two.' 2.0.0
git describe    # => 2.0.0

La sortie de git describe comprend les composants suivants:

1. La dernière balise accessible depuis le commit que vous demandez de décrire
2. Le nombre de validations entre la validation et la balise (si différent de zéro)
3. L'id (abrégé) de la validation (si # 2 est différent de zéro)

n ° 2 est ce qui rend la sortie monotone, n ° 3 est ce qui la rend unique. Les n ° 2 et n ° 3 sont omis, lorsque la validation est la balise, ce qui permet à git decrire de convenir également aux versions de production.

Answer 2

Un nombre croissant monotone correspondant à la validation actuelle pourrait être généré avec

git log --pretty=oneline | wc -l

qui renvoie un nombre unique. Vous pouvez également ajouter sha1 actuel à ce nombre, pour ajouter un caractère unique.

Cette approche est meilleure que git decrire , car elle ne nécessite pas l'ajout de balises et gère automatiquement les fusions.

Cela pourrait poser des problèmes de rebasement, mais le rebasement est "dangereux". opération quand même.

Answer 3

    git rev-list BRANCHNAME --count

cela nécessite beaucoup moins de ressources que

    git log --pretty=oneline | wc -l

Answer 4

La

balise git peut suffire à vos besoins. Choisissez un format de balise que tout le monde acceptera de ne pas utiliser autrement.

Remarque: lorsque vous balisez localement, un git push ne mettra pas à jour les balises sur le serveur. Utilisez git push --tags pour cela.

Answer 5

Vous devriez étudier git decrire . Il donne une chaîne unique décrivant la branche actuelle (ou tout identifiant de validation passé) en termes de dernière balise annotée, le nombre de validations depuis cette balise et un identifiant de validation abrégé de la tête de la branche.

Vous avez probablement une seule branche pour laquelle vous effectuez des versions de construction contrôlées. Dans ce cas, je taguerais un commit précoce avec un format de tag connu, puis utiliserais git describe avec l'option --match pour décrire le HEAD actuel par rapport au tag connu. Vous pouvez ensuite utiliser le résultat de git decrits tel quel ou, si vous souhaitez réellement utiliser un nombre unique, vous pouvez utiliser une expression régulière pour supprimer le numéro du tag.

En supposant que vous ne rembobiniez jamais la branche, le nombre de commits suivants identifiera toujours un point unique dans l'historique de la branche.

par exemple. (en utilisant bash ou similaire)

# make an annotated tag to an early build in the repository:
git tag -a build-origin "$some_old_commitid"

# describe the current HEAD against this tag and pull out a build number
expr "$(git describe --match build-origin)" : 'build-origin-\([0-9]*\)-g'

Answer 6

Je voudrais utiliser "Etiquettes". Créez une étiquette chaque fois que vous avez une génération réussie (ou même infructueuse) et vous pourrez identifier cette génération pour toujours. Ce n’est pas tout à fait la même chose, mais il fournit ces chiffres, tout en offrant les avantages du développement distribué.

Answer 7

Comme vous le savez probablement, git calcule un hachage (un nombre) identifiant de manière unique un nœud de l’historique. L'utilisation de ceux-ci, bien qu'ils ne soient pas strictement croissants, semble être suffisante. (Mieux encore, ils toujours correspondent à la source, donc si vous avez le hash, vous avez le même code.) Ce sont de gros chiffres, mais vous pouvez vous débrouiller avec 6 ou plus chiffres premiers.

Par exemple,

  

Ce bogue a été corrigé à 064f2ea ...

Answer 8

Avec Mercurial, vous pouvez utiliser la commande suivante:

# get the parents id, the local revision number and the tags
[yjost@myhost:~/my-repo]$ hg id -nibt
03b6399bc32b+ 23716+ default tip

Voir hg identifier