search

patacrep / patanet

Web interface for LaTeX songbook generation
GNU Affero General Public License v3.0
10 stars 3 forks source link

Gestion des versions #42

Open Luthaf opened 10 years ago

Luthaf commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

jmclem commented 10 years ago

Oui

Luthaf commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

Luthaf commented 10 years ago

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 :

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 commented 10 years ago

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 commented 10 years ago

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 :

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 :

Depots de chants (datadir)

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

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 commented 10 years ago

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.

Luthaf commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 : https://github.com/patacrep/songbook-web/issues/19#issuecomment-34161505, mais il y a longtemps.

Luthaf commented 10 years ago

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 :

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 :

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 ?