Traitement de l’expansion des mots clés SVN avec git-svn

Question

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

Pour le meilleur ou pour le pire, le projet sur lequel je travaille en ce moment nécessite le développement du mot clé SVN comme suit:

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 j'aimerais bien utiliser Git pour contrôler mes versions. Malheureusement, git-svn ne supporte pas cela, selon la documentation:

  

"Nous ignorons toutes les propriétés SVN sauf svn: exécutable"

.

Mais il ne semble pas trop difficile de faire émuler ce mot-clé par quelques points d'ancrage avant / après validation. Suis-je la première personne à vouloir cela? Quelqu'un a-t-il un code pour le faire?

Answer 1

Que se passe-t-il ici? Git est optimisé pour basculer le plus rapidement possible entre les branches. En particulier, git checkout est conçu pour ne toucher aucun fichier identique dans les deux branches.

Malheureusement, la substitution de mot clé RCS rompt cette tâche. Par exemple, pour utiliser $ Date $ , il faudrait que git checkout touche tous les fichiers de l'arborescence lors du changement de branche. Pour un référentiel de la taille du noyau Linux, cela entraînerait une interruption brutale.

En général, la meilleure solution consiste à baliser 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 validée postérieure à v0.5.15.1, avec un hachage SHA1 commençant par g61cde1d . Si vous collez le résultat 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 ceci explication de Lars Hjemli . En gros, $ Id $ est assez facile, et si vous utilisez archive Git , vous pouvez également utiliser $ Format $ .

Toutefois, si vous ne pouvez absolument pas éviter les mots clés RCS, procédez comme suit:

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

 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  smudge  et  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  vraiment  vous ne voulez pas faire cela pour plus de fichiers que nécessaire, sinon git perdra l'essentiel de sa vitesse. 
 > test.html
echo 'test.html filter=rcs-keyword' >> .gitattributes
git add test.html .gitattributes
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:

<*>

Si vous ne parvenez pas à obtenir les échappements du shell dans les commandes smudge et 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 vraiment vous ne voulez pas faire cela pour plus de fichiers que nécessaire, sinon git perdra l'essentiel de sa vitesse.

Answer 2

  

Malheureusement, mot clé RCS   la substitution casse ceci. Par exemple,   utiliser $ Date $ nécessiterait git   la caisse pour toucher tous les fichiers du   arbre lors du changement de branche.

Ce n'est pas vrai. $ Date $ etc., développez la valeur obtenue à l’arrivée. C'est beaucoup plus utile de toute façon. Donc, cela ne change pas sur les autres révisions ou branches, à moins que le fichier ne soit réellement ré-archivé. Du manuel 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 la fait tourner.

Answer 3

Voici un exemple de projet contenant la configuration et le code de filtre nécessaires pour ajouter la prise en charge des mots clés RCS à un projet git:

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

L’installation n’est pas aussi simple qu’on voudrait, mais cela semble fonctionner. Il utilise une paire de filtres smudge / clean écrite en perl (similaire à la réponse décrite par emk) et, oui, il touchera tous les fichiers avec les extensions définies dans .gitattributes, ce qui ralentira généralement un peu les choses.

Answer 4

Vous pouvez définir l'attribut ident sur vos fichiers, mais cela produirait des chaînes telles que

$Id: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef$

où deadbeef ... est le sha1 du blob correspondant à ce fichier. Si vous avez vraiment besoin de cette extension de mots clés et que vous en avez besoin dans le référentiel git (par opposition à une archive exportée), je pense que vous devrez utiliser l'attribut ident avec un script personnalisé. cela fait l'expansion pour vous. Le problème lié à l'utilisation d'un hook est que le fichier dans l'arborescence de travail ne correspond pas à l'index et que git penserait qu'il a été modifié.