Passer de CVS à Git: $ Id: $ equivalent?

J’ai lu un tas de questions sur les outils simples de contrôle du code source et Git semblait être un choix raisonnable. Je l’ai en place et ça marche bien jusqu’à présent. L’un des aspects que j’aime chez CVS est l’incrémentation automatique d’un numéro de version.

Je comprends que cela a moins de sens dans un référentiel dissortingbué, mais en tant que développeur, je veux / ai besoin de quelque chose comme ça. Laissez-moi vous expliquer pourquoi:

J’utilise Emacs. Périodiquement, je recherche et cherche de nouvelles versions des fichiers sources Lisp pour les paquets tiers. Disons que j’ai un fichier, foo.el, qui, selon l’en-tête, est la version 1.3; Si je regarde la dernière version et que je vois que c’est la version 1.143 ou 2.6, je sais que je suis loin derrière.

Si, au lieu de cela, je vois quelques hachages de 40 caractères, je ne saurai pas plus tard ou encore savoir plus tard. Je détesterais absolument si je devais vérifier manuellement ChangeLogs juste pour avoir une idée de ce que je suis désuet.

En tant que développeur, je veux, comme je le vois, étendre cette courtoisie aux utilisateurs de mon document (et je me trompe peut-être, mais laissez cela de côté). Je ne veux pas avoir à me rappeler d’incrémenter le foutu numéro à chaque fois, ou un horodatage ou quelque chose comme ça. C’est un vrai PITA, et je le sais par expérience.

Alors, quelles sont mes alternatives? Si je ne peux pas obtenir un équivalent $ Id: $, comment puis-je fournir ce que je cherche?

Je devrais mentionner que je m’attends à ce que l’utilisateur final n’ait pas installé Git et même s’il le fait, il n’aura pas de repository local (en fait, je m’attends à ne pas le rendre disponible de cette façon).

    Le SHA n’est qu’une représentation d’une version (bien que canonique). La commande git describe offre aux autres et le fait très bien.

    Par exemple, lorsque je lance git describe dans ma twig maître de ma source client Java memcached , je reçois ceci:

     2.2-16-gc0cd61a 

    Cela dit deux choses importantes:

    1. Il y a eu exactement 16 commits dans cet arbre depuis 2.2
    2. L’arbre source exact peut être affiché sur le clone de n’importe qui.

    Supposons, par exemple, que vous ayez emballé un fichier de version avec la source (ou même réécrit tout le contenu pour dissortingbution) pour afficher ce numéro. Disons que la version packagée était 2.2-12-g6c4ae7a (pas une version, mais une version valide).

    Vous pouvez maintenant voir exactement à quelle distance vous êtes derrière (4 commits), et vous pouvez voir exactement les 4 commits:

     # The RHS of the .. can be origin/master or empty, or whatever you want. % git log --pretty=format:"%h %an %s" 2.2-12-g6c4ae7a..2.2-16-gc0cd61a c0cd61a Dustin Sallings More sortinges to get a timeout. 8c489ff Dustin Sallings Made the timeout test run on every protocol on every bui fb326d5 Dustin Sallings Added a test for bug 35. fba04e9 Valeri Felberg Support passing an expiration date into CAS operations. 

    À l’heure actuelle, il existe un support pour $ Id: $ dans Git. Pour l’activer pour le fichier README, vous devez mettre “README ident” dans .gitatsortingbutes . Les caractères génériques sur les noms de fichiers sont pris en charge. Voir man gitatsortingbutes pour plus de détails.

    Ce n’est pas une demande déraisonnable de l’OP.

    Mon cas d’utilisation est:

    1. J’utilise Git pour mon propre code personnel, donc pas de collaboration avec les autres.
    2. Je conserve les scripts Bash du système qui peuvent entrer dans /usr/local/bin lorsqu’ils sont prêts.

    J’utilise trois machines distinctes avec le même référentiel Git. Il serait bon de savoir quelle “version” du fichier j’ai actuellement dans /usr/local/bin sans avoir à faire un manuel “diff -u “.

    Pour ceux d’entre vous qui sont négatifs, rappelez-vous qu’il existe d’autres cas d’utilisation. Tout le monde n’utilise pas Git pour le travail collaboratif avec les fichiers du référentiel Git comme leur emplacement “final”.

    En tout cas, la façon dont je l’ai fait était de créer un fichier d’atsortingbuts dans le référentiel comme ceci:

     cat .git/info/atsortingbutes # see man gitatsortingbutes *.sh ident *.pl ident *.cgi ident 

    Placez ensuite $ Id $ quelque part dans le fichier (j’aime bien le mettre après le shebang).

    Le commit. Notez que cela ne fait pas automatiquement l’expansion comme prévu. Vous devez re-co-fichier, par exemple,

     git commit foo.sh rm foo.sh git co foo.sh 

    Et puis vous verrez l’expansion, par exemple:

     $ head foo.sh #!/bin/sh # $Id: e184834e6757aac77fd0f71344934b1cd774e6d4 $ 

    Voici quelques informations utiles: Comment puis-je activer la chaîne d’identification pour un référentiel Git? .

    Je ne suis pas sûr que ce sera toujours dans Git. Pour citer Linus :

    “La notion même de substitution par mot-clé est tout à fait idiote. Il est sortingvial de faire” en dehors “du suivi du contenu réel, si vous voulez l’avoir lorsque vous lancez des arbres en tar-ball, etc.”

    Il est assez facile de vérifier le journal, cependant – si vous suivez la twig stable de foo.el, vous pouvez voir les nouveaux commits dans le journal de la twig stable qui ne figurent pas dans votre copie locale. Si vous souhaitez simuler le numéro de version interne de CVS, vous pouvez comparer l’horodatage du dernier commit.

    Edit: vous devez écrire ou utiliser les scripts de quelqu’un d’autre pour cela, bien sûr, ne pas le faire manuellement.

    Comme je l’ai déjà écrit:

    Le fait d’avoir généré automatiquement des tags d’identifiant qui affichent un numéro de version raisonnable est impossible avec les outils DSCM tels que Bazaar, car la ligne de développement de chacun peut être différente de tous les autres. Donc, quelqu’un pourrait se référer à la version “1.41” d’un fichier mais votre version “1.41” de ce fichier est différente.

    Fondamentalement, $ Id $ n’a aucun sens avec Bazaar, Git et d’autres outils de gestion de code source dissortingbués.

    J’ai eu le même problème. J’avais besoin d’une version plus simple qu’une chaîne de hachage et disponible pour les utilisateurs de l’outil sans avoir à se connecter au référentiel.

    Je l’ai fait avec un hook pré-validation de Git et j’ai changé mon script pour pouvoir se mettre à jour automatiquement.

    Je base la version sur le nombre de commits effectués. Il s’agit là d’une légère condition de concurrence, car deux personnes peuvent s’engager en même temps et toutes deux pensent qu’elles engagent le même numéro de version, mais nous n’avons pas beaucoup de développeurs sur ce projet.

    Le mien est en Ruby, mais ce n’est pas un code très complexe. Le script Ruby a:

     MYVERSION = '1.090' ## Call script to do updateVersion from .git/hooks/pre-commit def updateVersion # We add 1 because the next commit is probably one more - though this is a race commits = %x[git log #{$0} | grep '^commit ' | wc -l].to_i + 1 vers = "1.%0.3d" % commits t = File.read($0) t.gsub!(/^MYVERSION = '(.*)'$/, "MYVERSION = '#{vers}'") bak = $0+'.bak' File.open(bak,'w') { |f| f.puts t } perm = File.stat($0).mode & 0xfff File.rename(bak,$0) File.chmod(perm,$0) exit end 

    Et puis j’ai une option de ligne de commande (-updateVersion) qui appelle updateVersion pour l’outil.

    Enfin, je vais à la tête de Git et crée un script exécutable en .git/hooks/pre-commit .

    Le script change simplement en tête du répertoire Git et appelle mon script avec -updateVersion .

    Chaque fois que je coche, la variable MYVERSION est mise à jour en fonction du nombre de validations.

    Si avoir $ Keywords $ est essentiel pour vous, alors vous pourriez peut-être essayer de regarder Mercurial à la place? Il a une extension hgkeyword qui implémente ce que vous voulez. Mercurial est intéressant en tant que DVCS de toute façon.

    Quelque chose qui est fait avec les référentiels Git est d’utiliser l’object tag . Cela peut être utilisé pour marquer un commit avec n’importe quel type de chaîne et peut être utilisé pour marquer des versions. Vous pouvez voir ces balises dans un référentiel avec la commande git tag , qui renvoie toutes les balises.

    Il est facile de vérifier une étiquette. Par exemple, s’il existe une balise v1.1 vous pouvez vérifier cette balise dans une twig comme celle-ci:

     git checkout -b v1.1 

    Comme il s’agit d’un object de premier niveau, vous pourrez voir l’historique complet de cette validation, ainsi que pouvoir exécuter diffs, apporter des modifications et fusionner.

    De plus, une balise persiste, même si la twig sur laquelle elle se trouvait a été supprimée sans être fusionnée dans la ligne principale.

    Si vous voulez simplement que les gens puissent se faire une idée de ce qu’ils sont, Git peut les informer de plusieurs façons assez simples. Ils comparent par exemple les dates du dernier engagement sur leur coffre et votre coffre. Ils peuvent utiliser git cherry pour voir combien de commits ont eu lieu dans votre coffre qui ne sont pas présents dans le leur.

    Si c’est tout ce que vous voulez, je chercherais un moyen de le fournir sans numéro de version.

    De plus, je ne prendrais pas la courtoisie à qui que ce soit, sauf si vous êtes sûr de le vouloir. 🙂

    Si je comprends bien, essentiellement, vous voulez savoir combien de commits ont eu lieu sur un fichier donné depuis votre dernière mise à jour.

    Obtenez d’abord les modifications dans l’origine distante, mais ne les fusionnez pas dans votre twig principale:

     % git fetch 

    Ensuite, obtenez un journal des modifications survenues sur un fichier donné entre votre twig principale et l’ origin/master distant.

     % git log master..origin/master foo.el 

    Cela vous donne les messages de journal de tous les commits qui se sont produits dans le référentiel distant depuis la dernière fois que vous avez fusionné origin/master dans votre master .

    Si vous voulez simplement compter les modifications, dirigez-le vers wc . Dis, comme ça:

     % git rev-list master..origin/master foo.el | wc -l 

    Les ID RCS sont intéressants pour les projets à fichier unique, mais pour tout autre, $ Id $ ne dit rien sur le projet (sauf si vous effectuez des vérifications factices forcées dans un fichier de version factice).

    On pourrait encore s’intéresser à la manière d’obtenir les équivalents de $ Author $, $ Date $, $ Revision $, $ RCSfile $, etc. au niveau du fichier ou au niveau de la validation (comment les placer là où des mots-clés sont différents) question). Je n’ai pas de réponse à ce sujet, mais je pense qu’il est nécessaire de les mettre à jour, en particulier lorsque les fichiers (désormais en Git) proviennent de systèmes compatibles RCS (CVS).

    Ces mots-clés peuvent être intéressants si les sources sont dissortingbuées séparément de tout repository Git (c’est ce que je fais aussi). Ma solution est comme ceci:

    Chaque projet a son propre répertoire et dans la racine du projet, j’ai un fichier texte nommé .version dont le contenu décrit la version actuelle (le nom qui sera utilisé lors de l’exportation des sources).

    Tout en travaillant pour la prochaine version, un script extrait ce numéro .version , un descripteur de version de Git (comme git describe ) et un numéro de construction monotone dans .build (plus l’hôte et la date) dans un fichier source généré automatiquement programme, de sorte que vous pouvez savoir de quelle source et quand il a été construit.

    Je développe de nouvelles fonctionnalités dans des twigs distinctes, et la première chose à faire est d’append n (pour “next”) à la chaîne .version (plusieurs twigs provenant de la même racine utiliseront le même numéro de .version temporaire). Avant la publication, je décide quelles twigs fusionner (tout devrait avoir la même .version ). Avant de .version la fusion, je .version à jour le .version au numéro suivant (mise à jour majeure ou mineure, en fonction des fonctionnalités fusionnées).

    Je suis d’accord avec ceux qui pensent que le remplacement de jetons appartient à la création d’outils plutôt qu’aux outils de contrôle de version.

    Vous devez disposer d’un outil de version automatisée pour définir les ID de version dans vos sources au moment où la version est balisée.

    Depuis que vous utilisez Emacs, vous pourriez avoir de la chance 🙂

    Je suis tombé sur cette question par hasard, et aussi par hasard, je suis venu par Lively il y a quelques jours, un paquet Emacs qui permet d’avoir des morceaux vivants d’Emacs Lisp dans votre document. Je n’ai pas essayé d’être honnête, mais cela m’est venu à l’esprit en lisant ceci.

    Je suis également venu du SCCS, du RCS et du CVS ( %W% %G% %U% ).

    J’ai eu un défi similaire. Je voulais savoir quelle version d’un code était sur un système quelconque qui l’exécutait. Le système peut ou non être connecté à un réseau. Le système peut ou non avoir installé Git. Le référentiel GitHub peut ou non être installé sur le système.

    Je voulais la même solution pour plusieurs types de code (.sh, .go, .yml, .xml, etc.). Je voulais que toute personne sans connaissance de Git ou GitHub puisse répondre à la question “Quelle version utilisez-vous?”

    Donc, j’ai écrit ce que j’appelle un wrapper autour de quelques commandes Git. Je l’utilise pour marquer un fichier avec un numéro de version et des informations. Cela résout mon défi. Cela peut vous aider.

    https://github.com/BradleyA/markit

     git clone https://github.com/BradleyA/markit cd markit 

    Pour appliquer l’extension à tous les fichiers de tous les sous-répertoires du référentiel, ajoutez un fichier .gitatsortingbutes au répertoire de niveau supérieur du référentiel (c’est-à-dire où vous .gitignore normalement le fichier .gitignore ) contenant:

     * ident 

    Pour que cela soit effectif, vous devez d’abord procéder à une extraction efficace du ou des fichiers, tels que leur suppression ou leur modification. Ensuite, restaurez-les avec:

     git checkout . 

    Et vous devriez voir $Id$ remplacé par quelque chose comme:

     $Id: ea701b0bb744c90c620f315e2438bc6b764cdb87 $ 

    De man gitatsortingbutes :

    ident

    Lorsque l’atsortingbut ident est défini pour un chemin, Git remplace $ Id $ dans l’object blob par $ Id: suivi du nom d’object blob hexadécimal à 40 caractères, suivi d’un signe dollar $ lors du paiement. Toute séquence d’octets commençant par $ Id: et se terminant par $ dans le fichier worktree est remplacée par $ Id $ lors de l’enregistrement.

    Cet identifiant changera chaque fois qu’une nouvelle version du fichier sera validée.