Seb35
commented
6 years ago Entièrement d’accord – je crois qu’on en avait discuté anyway. Cela permettra de faire une meilleure séparation entre la vigueur passée et la vigueur à venir, moins certaine.
Je viens de commiter une proposition dans la branche reorg-git avec d’autres modifications dans l’organisation des dépôts Git :
- Ajout de la date de publication de la base LEGI dans le champ "committer" de Git, ça permettra d’améliorer la traçabilité des calculs,
- Renommage de la branche par défaut : "texte" ou "articles" selon qu’il y a un fichier unique avec tout le texte ou un fichier par article - j’ai hésité à mettre d’autres nom : "vigueur" (mais j’ai peur que ça soit ambigüe car si on ne met pas à jour le dépôt Git, ça ne sera plus en vigueur à un moment donné) ou "publication" (neutre)
- Les versions futures sont dans une branche : "futur-texte" ou "futur-articles" - j’ai choisi de toujours mettre une branche "futur-*" même s’il n’y a pas de vigueur future, à voir si c’est un bon choix, l’alternative étant de ne pas mettre de telle branche s’il n’y a pas de vigueur future
Pas strictement lié à cette issue, mais je pense mettre par défaut dans les dépôts Git à la fois le texte en version "fichier unique" et en "un fichier par article", d’autant que c’est quasiment gratuit en stockage du fait de la compression de Git. En lien avec ça et plus généralement, je me demande si ça serait intéressant d’utiliser les espaces de noms Git (pour éventuellement ajouter des variantes Markdown/RestructedText/etc, avec ou sans liens internes, etc.), et si oui comment bien faire.
Les dépôts Git généré font apparaitre des commits à des dates dans le futur :
2222-02-22 = code pour “date future indéterminée” 2999-01-02 = code pour null/None = pas de date de fin de vigueur [prévue]
Il serait mieux de mettre ces commits sur une branche spécifique.