Gestion des versions

[Luthaf]

Comme suite a la question #19, se pose la question de comment sont gérées et affichées a l'utilisateur les différentes versions d'un chant.

[jmclem]

Ma réponse du moment (s'il s'agit bien des versions au sens VCS dont tu parles) : à différer sur une version future

[Luthaf]

En même temps que l’édition de chants du coup ?

[jmclem]

Oui

[Luthaf]

Je propose que songbook-web travaille sur une branche qui lui soit propre pour les éditions/ajouts à la base de données de chants. Ainsi, la responsabilité des merges revient aux administrateurs.

[oliverpool]

Je suis assez d'accord avec cette vision.

Les modifications des chants sur le site modifient en direct un repo GIT propre au site,
et l'on peut synchroniser régulièrement ces modifs avec un repo github facilement accessible publiquement (ou une branche de songbook-data que seul le site-web modifie et que l'on peut merger si l'on veut)

[Luthaf]

J'était en train de me dire que ça pouvais être pas mal de gérer plusieurs dépôts. Du coup il y aurait le dépôt des chants personnels (qu'un seul utilisateur peut accéder), celui des chants scouts, celui des chants religieux. Pour moi au moins ces trois là n'ont pas vocation a être mergés dans songbook-data mais peuvent valoir le coup pour le site web.

PS : @oliverpool, heureux que tu ai trouvé le temps de venir faire un tour !

[oliverpool]

Je pense qu'il n'est pas indispensable des dépôts séparés (ca devient complexe à gérer, et la catégorisation n'est pas toujours triviale...)

---

Mais implémenter une gestion de tags ("religieux", "scout", "à boire"...) pourrait être intéressante !

[Luthaf]

Les tags pourquoi pas, c'est simple et on peut réussir a mettre tout le monde d'accord si une chanson peut avoir plusieurs tags ("chanson a boire" et "rock" et "romantique").

Pour les dépôts, le problème est surtout que pour moi certains chants, religieux en particulier, ou scouts n'ont pas vraiment leur place dans songbook-data.

[oliverpool]

Et si on fait une branche de songbook-data ? (appelée 'web' ou 'scout')

[Luthaf]

Dans ce cas, on est oblige de faire un appel git pour récupérer chaque chanson (les branches ne sont pas sur le système de fichier par défaut), ce qui conduirait a une charge plus grande. On a besoin des fichiers pour :

• L'affichage des chansons tant que l'HTML n'est pas mis en cache
• L'edition des chansons
• Et surtout la compilation !

En fait ce dernier point interdit totalement d'avoir plusieurs répertoires ... On est oblige de tout mettre dans le même. Du coup le problème est plus grave que ca. La version simple est alors de s'en tenir a songbook-data et d'ajouter des chants dans une branche séparée. Mais cela peut conduire a des conflits de noms lors des fusions.

Sinon, on peut modifier songbook-core pour qu'il n'utilise datadir que si les chemins de chansons ne sont pas absolus, et produire les chemins dans songbook-web avec les dépôts différents.

[oliverpool]

les branches ne sont pas sur le système de fichier par défaut

avec git checkout, tu peut décider de la branche qui est sur le système de fichier, non ?

Pour les 'sous-répertoires' spéciaux, on peut faire un sous-dossier ignoré par git ?

[jmclem]

J'était en train de me dire que ça pouvais être pas mal de gérer plusieurs dépôts. Du coup il y aurait le dépôt des chants personnels (qu'un seul utilisateur peut accéder), celui des chants scouts, celui des chants religieux. Pour moi au moins ces trois là n'ont pas vocation a être mergés dans songbook-data mais peuvent valoir le coup pour le site web.

.

Je pense qu'il n'est pas indispensable des dépôts séparés (ca devient complexe à gérer, et la catégorisation n'est pas toujours triviale...)

J'ai depuis le début l'idée qu'il serait bien de pouvoir gérer plusieurs 'sources', git ou fichiers ou db ou rest ou jenesaiskoi.

Par exemple, je suis l'admin d'un site songbook-web pour ma troupe scout. Dans une page d'admin, je configure 3 sources :

• songbook-data, qui a plein de chants qui m'intéressent (git)
• un dépôt fait par jenesaiski qui a plein de chants scouts (git aussi)
• une arborescence de fichiers où je mets les miens

Pour les utilisateurs, les chants des trois sources seront disponibles (avec éventuellement le nom de la source).

Ok on est pas obligé de passer au REST tout de suite ;)

[Luthaf]

une arborescence de fichiers où je mets les miens

Ca peut être un dépôt git local. Comme ca tout fonctionne de la même manière.

[jmclem]

Ca peut être un dépôt git local. Comme ca tout fonctionne de la même manière.

je pense qu'il serait judicieux de ne pas placer git au coeur du produit. Je préférerais fonctionner avec des interfaces (comme django a des pilotes pour les différents type de bdd) qui exposent des fonctionnalités en fonction de leur capacité.

et pouvoir utiliser plusieurs sources - comme django peut utiliser plusieurs bdd pour une app.

[Luthaf]

git permet de ne pas avoir a se soucier de la gestion des versions des fichiers, ce qui nous facilite la vie. Mais si tu es motivé pour écrire d'autres interfaces, ne te prive pas !

[Luthaf]

Du coup, pour l'implémentation, je pensais à un modèle complet, du style

SongsDataBase
    path
    head (dernière version en BDD, pour les mises à jour)
    type (si jamais on a besoin de systèmes de fichiers, ...)

Et ajouter une ForeignerKey dans le modèle Song. Ça pourrait être bien d'ajouter importsongs comme une action depuis l'interface d’administration.

[Luthaf]

Pour ajouter des actions dans l'interface d'administration, il y a ça qui est bien :
https://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/

[Luthaf]

Gestion des versions

Pour en revenir a la problématique initiale ("Gestion des versions"), est-ce que l'on ajoute un champ hash a ItemsInSongbook pour stocker la version de la chanson lorsque le carnet a été généré ? On effectue ensuite la comparaison pour dire si le carnet est a jour ou non, puis on affiche un message (discret) a l'utilisateur "des chants ont été modifies pour ce carnet, voulez-vous voir les modifications ?".

Sur la page des modifications, on affiche un diff, et on laisse un choix :

• Utiliser les nouvelles versions : on met simplement a jour les valeurs de hash dans ItemsinSongbook
• Utiliser les anciennes versions. Dans ce cas, une chanson privée est crée dans le dépôt des chansons privées, avec l'ancien contenu du fichier .sg, et ItemInsongbook est modifie en conséquence.

Depots de chants (datadir)

Ce qui me permet de faire la transition vers les dépôts nécessaires :

• Un dépôt de chansons privée, associées a un utilisateur particulier et auxquelles les autres n'ont pas accès.
• Un dépôt avec accès en écriture, pour les nouveaux chants entrés depuis l'interface web.
• Zéro, un ou plusieurs dépôts avec accès au moins en lecture, entrés dans les réglages ou via la zone d'administration, sous la forme ("chemin local", "url git"). Ceux la peuvent être mis a jour (== git pull), et pourquoi pas renvoyer leurs mises a jour sur l'origine (== git push). Dans un premier temps, push et pull doivent être fait a la main, a terme pourquoi pas proposer une interface web pour le faire (et régler les conflits de merge).

Je pense qu'il serait aussi utile d'ajouter une ForeignKey dans Song qui pointe vers SongDatadir, histoire de savoir ou chercher les fichiers. (oui, je me répète un peu).

[jmclem]

Utiliser les anciennes versions. Dans ce cas, une chanson privée est crée dans le dépôt des chansons privées, avec l'ancien contenu du fichier .sg, et ItemInsongbook est modifie en conséquence

Pourquoi créer une chanson privée? Pourquoi ne pas accéder simplement à l'ancienne version de la repo ?

J'ai relu tout le fil, voici comment je 'sens' les choses.

Tout part pour moi de l'idée que ce projet pourrait être multiplié : plusieurs personnes l'installent sur leur serveur et éventuellement créent une repo qui est propre à leur centre d'intérêt. Ces repos sont éventuellement rendues publiques.

• je souhaite ainsi sur mon install pouvoir configurer plusieurs repos, parce que je veux réutiliser la repo orientée "rock" de Elvis, la repo "Lagerfeuer" de Wolfgang et la repo orientée "Liberté, amitié et maison bleue" de Maxime
• quand j'ajoute des chants, je choisis dans quelle repo je souhaite l'ajouter. Ça reste en local, il n'y a pas de push automatique vers les repos d'origine.
• en tant qu'admin, je peux mettre à jour une repo étrangère (si vcs) par pull, et mettre à disposition un patch/pull request
• je n'ai peut-être pas git à dispo sur mon serveur (mutu) ; le truc devrait pouvoir fonctionner avec des fichiers simples. À ce moment, bye la gestion de version, c'est toujours la version actuelle du fichier qui est prise en compte.
• l'idée des tags me semble tout à fait bien. Les tags sont-ils globaux (les mêmes pour tout le monde), personnalisés ou un mélange des deux ?

[Luthaf]

Pourquoi créer une chanson privée? Pourquoi ne pas accéder simplement à l'ancienne version de la repo ?

Parce que l'on a besoin d'un accès simultané a tous les fichiers pour pouvoir compiler le carnet. LaTeX ne connais rien de git. On peut contourner ce problème, a coup de write18 et de git checkout, mais ce n'est pas le plus simple ni le plus efficace (et la compilation est déjà lente).

quand j'ajoute des chants, je choisis dans quelle repo je souhaite l'ajouter. Ça reste en local, il n'y a pas de push automatique vers les repos d'origine.

Le problème est que soit on expose a l'utilisateur qu'il y a 4-5 endroits différents ou mettre ses chants, et il doit choisir, soit on fait tous les ajouts a un endroits particulier, quitte a partager les nouveaux fichiers. Par contre, les modifications des chants existant ont en effet lieu dans les repos d'origine, et l'on peut créer des patch/pull request a la main pour mettre a jour ces chansons.

je n'ai peut-être pas git à dispo sur mon serveur (mutu) ; le truc devrait pouvoir fonctionner avec des fichiers simples. À ce moment, bye la gestion de version, c'est toujours la version actuelle du fichier qui est prise en compte.

Si tu n'as pas git de disponible parce que tu es sur un mutualisé, il est très peu probable que tu puisse quand même installer pdflatex et ses 1G de packages, Python en version 2.7 et Django.

D'autre part, on peut se passer de la gestion de version, mais on perd une protection contre les utilisateurs mal-intentionnées qui viennent mettre n'importe quoi dans les chansons. Il faut alors mettre en place des backups réguliers, ce qui n'est pas forcement évident non plus sur un mutualise.

l'idée des tags me semble tout à fait bien. Les tags sont-ils globaux (les mêmes pour tout le monde), personnalisés ou un mélange des deux ?

Je pense que des tags globaux sont plus utiles. Ils serviraient surtout a faire une recherche/un tri sur les chants depuis le web, mais ils n’apparaîtrai pas sur les PDF. J'ouvre une issue pour ca.

[jmclem]

Si tu n'as pas git de disponible parce que tu es sur un mutualisé, il est très peu probable que tu puisse quand même installer pdflatex et ses 1G de packages, Python en version 2.7 et Django.

hmmm, ... ouais, tu as raison ;)

[jmclem]

On peut contourner ce problème, a coup de write18 et de git checkout, mais ce n'est pas le plus simple ni le plus efficace (et la compilation est déjà lente).

J'ai l'impression que le déplacement dans une repo privée n'est pas trivial non plus; dans la version la plus simple, on perd le lien avec l'objet git, donc avec les versions. Si je commence à garder un lien vers la repo originale, ça risque de devenir pénible à gérer.
Je préférerais garder la référence vers la version de la repo et créer un fichier temporaire au moment de la génération.

[Luthaf]

J'ai l'impression que le déplacement dans une repo privée n'est pas trivial non plus; dans la version la plus simple, on perd le lien avec l'objet git, donc avec les versions. Si je commence à garder un lien vers la repo originale, ça risque de devenir pénible à gérer.

Si on veut vraiment garder l'histoire, on peut faire ça avec des patchs git. Sur So, j'ai trouvé ça, il faut voir l'efficacité, et la facilité à la faire avec GitPython. Mais je crois qu'il est possible d’exécuter n'importe quel commande git avec GitPython, me trompe-je ?

Je préférerais garder la référence vers la version de la repo et créer un fichier temporaire au moment de la génération.

Cela peut être une solution plus simple en effet. On crée un fichier dans /tmp (à coup de tempdir Python), puis on inclue ce fichier avec son chemin absolu. Tu sais s'il est possible d'extraire un fichier à un commit donné dans git sans faire un checkout global ? Le dépôt pouvant être utilisé par d'autres processus en même temps.

EDIT : git show semble faire le boulot. Et avec GitPython, on peut faire repo.git.execute("git show sha:path/to/file > /tmp/file.sg").

RE-EDIT: en fait, on avais déjà fini par trouver cette solution : #19 (comment), mais il y a longtemps.

[Luthaf]

Du coup, résumé suivant :

Plusieurs dépôts

Le site doit gérer plusieurs dépôts, avec deux dépôts obligatoires, et un nombre quelconque de dépôts facultatifs. Les dépôts obligatoires sont écrits dans une valeur du fichier settings.py et sont regroupes dans un dictionnaire dont les clefs sont :

• default: le dépôt local pour les ajouts de chants
• private le dépôt local pour les chants privés.
• others un chemin dans lequel cloner les autres dépôts.

Tous les autres dépôts sont ajoutes via leurs URL dans l'interface d'administration, et peuvent être mis a jour soit en ligne de commande manage.py importsongs, soit depuis l'interface d'administration.

Nouvelles chansons

Au moins dans un premier temps, les nouvelles chansons sont ajoutées uniquement dans les dépôt locaux: default ou private. Il sera ensuite possible d'utiliser git cherry-pick pour récupérer les historiques de certains fichiers et les partager avec d'autres dépôts.

Modification des chansons

Lorsqu'une chanson est modifiée, son object_hash est mis a jour. L'ensemble des object_hash sont comparés lors de l'affichage des carnets, et un diff est présenté a l'utilisateur qui peut choisir d'accepter les modifications, ou de les rejeter. Si il les rejette, lors de la prochaine compilation, ce chant sera extrait et placé dans un dossier temporaire.

Suppression des chansons

Si une chanson est supprimée, on met object_hash a NULL. L'utilisateur est prévenu lors de sa prochaine connexion, mais n'a pas le choix de garder ou pas le chant. La chanson ignorée lors de la compilation.

Travail a faire

Il va falloir travailler a deux endroits principalement :

• Dans la compilation des fichiers, get_as_json devrait se charger d'extraire les fichiers dans les dossiers temporaires et de ne rien retourner si le fichier n'existe plus, ainsi que de retourner l'ensemble des datadirs utilises.
• Dans l'import/mise a jour des chants.
  • Il faut stoker le HEAD des dépôts pour savoir si une mise a jour est nécessaire
  • Il faut stoker refactoriser un rien la commande actuelle pour l'adapter a plusieurs dépôts.
  • Il faut écrire toute l'interface d'extraction d'information et de présentation des diffs.

Questions restantes

Faut-il supprimer a la main les dossiers temporaires ?

Que fait-on si l'utilisateur refuse les modifications, puis qu'il se reconnecte ? On affiche de nouveau ces modifications, ou on stocke quelque part le fait qu'il les ait déjà refusé ?

Si un chant est modifie pendant une compilation, que se passe-t-il ?