Traitement des mots-clés SVN avec git-svn

J’ai récemment posé une question sur l’ expansion des mots clés dans Git et je suis prêt à accepter le design pour ne pas vraiment supporter cette idée dans Git.

Pour le meilleur ou pour le pire, le projet sur lequel je travaille actuellement nécessite une extension de mot-clé SVN comme ceci:

svn propset svn:keywords "Id" expl3.dtx 

pour garder cette chaîne à jour:

 $Id: expl3.dtx 803 2008-09-11 14:01:58Z will $ 

Mais je voudrais bien utiliser Git pour faire mon contrôle de version. Malheureusement, git-svn ne supporte pas cela, selon les documents:

“Nous ignorons toutes les propriétés SVN sauf svn: executable”

Mais il ne semble pas trop compliqué d’avoir ce mot-clé imité par quelques crochets avant / après validation. Suis-je la première personne à vouloir cela? Est-ce que quelqu’un a du code pour le faire?

Qu’est-ce qui se passe ici: Git est optimisé pour basculer entre les twigs le plus rapidement possible. En particulier, git checkout est conçu pour ne toucher aucun fichier identique dans les deux twigs.

Malheureusement, la substitution par mot-clé RCS casse cela. Par exemple, utiliser $Date$ nécessiterait une git checkout pour toucher tous les fichiers de l’arborescence lors du changement de twig. Pour un référentiel de la taille du kernel Linux, tout s’arrêterait.

En général, le mieux est de marquer au moins une version:

 $ git tag v0.5.whatever 

… puis appelez la commande suivante depuis votre Makefile:

 $ git describe --tags v0.5.15.1-6-g61cde1d 

Ici, git me dit que je travaille sur une version anonyme 6 validée après la v0.5.15.1, avec un hash SHA1 commençant par g61cde1d . Si vous collez la sortie de cette commande dans un fichier *.h quelque part, vous êtes en affaires et vous n’aurez aucun problème à relier le logiciel publié au code source. C’est la façon préférée de faire les choses.

Si vous ne pouvez pas éviter d’utiliser des mots-clés RCS, vous pouvez commencer par cette explication de Lars Hjemli . Fondamentalement, $Id$ est assez facile, et si vous utilisez l’ git archive , vous pouvez également utiliser $Format$ .

Mais si vous ne pouvez absolument pas éviter les mots-clés RCS, vous devez commencer par:

 git config filter.rcs-keyword.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"' git config filter.rcs-keyword.smudge 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date: `date`\\\$/"' echo '$Date$' > test.html echo 'test.html filter=rcs-keyword' >> .gitatsortingbutes git add test.html .gitatsortingbutes git commit -m "Experimental RCS keyword support for git" rm test.html git checkout test.html cat test.html 

Sur mon système, je reçois:

 $Date: Tue Sep 16 10:15:02 EDT 2008$ 

Si vous ne parvenez pas à obtenir les échappements du shell dans les commandes de clean et de clean , écrivez simplement vos propres scripts Perl pour développer et supprimer les mots-clés RCS, respectivement, et utilisez ces scripts comme filtre.

Notez que vous ne voulez vraiment pas faire cela pour plus de fichiers que nécessaire, ou que git perdra la majeure partie de sa vitesse.

Malheureusement, la substitution par mot-clé RCS casse cela. Par exemple, utiliser $ Date $ nécessiterait une vérification git pour toucher tous les fichiers de l’arborescence lors du changement de twig.

Ce n’est pas vrai. $ Date $ etc., augmentez à la valeur qui correspond à l’heure d’arrivée. C’est beaucoup plus utile de toute façon. Donc, cela ne change pas sur les autres révisions ou twigs, à moins que le fichier ne soit ré-enregistré. A partir du manuel du RCS:

  $Date$ The date and time the revision was checked in. With -zzone a numeric time zone offset is appended; otherwise, the date is UTC. 

Cela signifie également que la réponse suggérée ci-dessus, avec le filtre rcs-keyword.smudge, est incorrecte. Il insère l’heure / la date de la caisse, ou tout ce qui le fait fonctionner.

Voici un exemple de projet contenant la configuration et le code de filtrage requirejs pour append la prise en charge du mot-clé RCS à un projet git:

https://github.com/turon/git-rcs-keywords

Ce n’est pas aussi simple à configurer que l’on voudrait, mais cela semble fonctionner. Il utilise une paire de filtre smudge / clean écrite en perl (similaire à la réponse de emk), et oui, il touchera tous les fichiers avec les extensions définies dans .gitatsortingbutes, ralentissant généralement un peu les choses.

Vous pouvez définir l’atsortingbut ident sur vos fichiers, mais cela produirait des chaînes comme

 $Id: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef$ 

deadbeef... est le sha1 du blob correspondant à ce fichier. Si vous avez vraiment besoin de cette extension de mot-clé et que vous en avez besoin dans le repository git (par opposition à une archive exscope), je pense que vous devrez utiliser ident gitatsortingbute avec un script personnalisé qui effectue l’extension pour vous. Le problème avec l’utilisation d’un hook est que le fichier dans l’arborescence ne correspondrait pas à l’index, et git penserait qu’il a été modifié.