l'accent dans éditor est il voulu ?
D'où provient ce bloc ?
Valery Fremaux
Mensagem enviada por Valery Fremaux
Le rapport de cours anciennement course/report/trainingsessions, compilant les temps d'usage fournis par le bloc block/use_stats est désormais disponible pour Moodle 2 :
L'espace MoodeLab de gestion de e plugin : http://ateliers.moodlelab.fr/course/view.php?id=56
Pour les développeurs et intégrateurs :
Requestionnement méthodologique....
Git fonctionne par enregistrement différentiel.
A chaque commit d"un fichier modifié, il enregistre en fait les diff de la version antérieure avec la nouvelle version et compresse cette information dans un digest qui sert également d'identifiant.
Au moment d'un commit on met donc un commentaire qui dit ce qui a changé.
L'intérêt de Git est de pouvoir répercuter une modification partielle (cherry-pick) qui met à jour certains changements de code lié à une fonctionnalité particulière.
De ce fait alors que sous CVS on enregistre un état de fichiers, et que ce qui reste important, ce sont les état "identifiés" par exemple pat des Tags, placés sur chaque fichier, ce qui est important pour Git est LE commit où on s'arrête pour obtenir la version de code... (enfin, ça c'est ma perception actuelle).
Ma première impression est que tenir une rigueur des commits dans le bon ordre et dans les stricts frontières du "packging" de chaque fonctionnalité me semble relativement innaccessible, sauf pour des codeurs qui font ça toute la journée.
Il m'arrive très fréquemment d'acumuler des fixes très différents dans les fichiers avant de passer un commit effectif en référentiel.
La question est alors :
Y a t-il quelques règles simples de bonnes pratiques pour que le principe de commit sous Git reste effectivement utilisable pour ce qu'il est prévi ? Quels sont les pièges ?
Je vois bien le côté "développement" et mise au point, ma question qui suit est :
comment à partir du référentiel de chaque version qui contient TOUT moodle, peux tu mettre à jour les réfétentiels partiels du module ?
Est-ce que par exemple la piste suivante est possible ? :
Step 1 : On met sous Git la version complète de Moodle sans aucun développement. on ajoute les fichiers standard, mais on n'ajoute jamais les fichiers des plugins développé
Step 2 : On fait un référentiel Git juste au dessus des modules ajoutés (par exemple, dans mod, et on y ajoute uniquement que les plugins en développement, upstreamés dans github.
L'idée reste, avant tout, de ne pas avoir une chaine de 15 manips à faire lorsqu'un veut republier un fix depuis l'un des projets d'intégration.
J'ai encore énormément de mal à me représenter une stratégie de gestion des configurations à partir de commits différentiels. A grande échelle, ça ne passe pas. Ca va bien sur un projet ou ou navigigue dans 2 ou 3 repos. mais quand on en gère 80 en configuration différentes (avec à la fois des variations de version mais aussi de choix de plugins)... là je sèche... depuis 3 ans sur la question.
La roue tournant dans ce sens, allons y voir un peu plus profond...
Evidemment après quelques manoeuvres et quelques repository installés et manipulés, une tonne de question apparait. Si des "GiTeux" sont dans le coin.... you welcome.
Step 1 :Me connecter à GitHub et créer un compte .. ok
Step 2 : Installer Gitbash et Git GUI .... ok
Step 3 : Faire un premier Repo ... je commence avec moodle-block_dashboard
>> sur github : on crée le nouveau repo (avec un fichier README)
>> en local
mkdir /d/GitRepos/moodle-block_dashboard
cd /d/GitRepos/moodle-block_dashboard
git init
(il y a des règles de "naming" précises pour nommer les répertoires Git de "composants Moodle").
On prépare les deux "pointeurs" d'écriture et de soumission (ce ne sont pas les mêmes protocoles) :
git remote add upstream git://github.com/vfremaux/moodle-block_dashboard.git
git remote add origin git@github.com:vfremaux/moodle-block_dashboad.git
Le premier définit le label "upstream" comme étant la source de modifications distantes (la source des "update" pour les CVSeux comme moi).
Le deuxième définit la destination des soumissions (commits)
ça marche après un joli fight autour de ssh-agent sous Windows, et une variable GIT_SSH que l'installation de Git Bash positionne mal (par défaut, il utilise un eventuel Putty local, au lieu d'utiliser le client ssh lvré avc Git).
Step 4 : Charger le code pour Moodle 2 dans la branche master ... .ok
>> En local : copier les fichiers du bloc dans le répertoire dépôt, pui on ajoute tous les fichiers pou indexation :
git add *
On commite (valide) tous ces fichiers
git commit -m "first load of source code"
Puis on pousse dans github :
git push origin master
Là ça ne marche pas du premier coup : la création du repository dans gitub a commité le README, le local n'est pas à jour. Il faut d'abord récupérer l'état à jour de github :
git pull origin master
git push origin master
Step 5 : Crér une branche MOODLE_19_STABLE dans le Repo local
git checkout -b MOODLE_19_STABLE
En apparence rien n'a changé, mais en fait, la création de la branche fait une dérivation pour les prochains changement de code
On écrase le code Moodle 2 par le code Moodle 1.9 (par exemple avec un outil de merge comme WinMerge)
Il faut intégrer toutes les modifications nouvelles, fichiers nouveaux et changements sur les fichies existants.
GitGUI peut être utile à ce moment pour visuaiser en une fois toutes les modifs, faire l'ajout (add) puis l'ensemble des commits.
On pousse le code dela branche vers github :
git push origin MOODLE_19_STABLE
A l'arrivée, une branche distante MOODLE_19_STABLE est bien créée avec le code de 1.9
Voila le résultat de la première leçon de Git sous github.
Conclusion
Une fois les pb de ssh passés, cela est assez simple à mettre en oeuvre.
Il faut donc prévoir en effet un repository autonome par plugin, si la gestion de la version code veut être géré plugin par plugin (ce qui est mieux pour un dépôt "public" de proposition de code).
Par contre, pour un dépôt d'intégration, il vaut donc mieux un dépôt monolithique avec tous les composants à l'intérieur.
Avantages percus :
Git favorise effectivement le développement "social" à défaut d'être vraiment collaboratif : il permet des échanges plus simples entre les multiples versions locales de plusieurs développeurs/exploitants du même bout de code. (je ne suis pas sûr qu'il facilite la négociaiton fonctionnelle, cependant). Il est donc assez simple de "forker" sa propre version (bidouille ?) locale pour son projet propre.
Inconvénients percus: (IMHO)
La gestion "modulaire" d'intégration est néamnoins très lourde et demande réellement une étude du "process" entre les développeurs et les serveurs de production, ainsi que la création de tout un outillage de scripts préécrits... (sinon, tu bouffe ton bénéfice !!).
Maintenant, plein de questions :
Question 1 : Précisément, par rapport aux multiples dépôts individuels des composants séparés : comment réassembler des composants dans un dépôt "Moodle" complet, en intégrant le code standard + les composants provnant de divers dépôt... ?
Question 2 : Dans Git, le code "visible" en termes de fichiers éditables n'est que la branche active. (par exemple, dans l'exemple ci-dessus du block dashboad, on ne peut voir à la fois les fichiers de la banche "master" et ceux de la branche "MOODLE_19_STABLE". Les opérations de checkout commutent bien le code entre les deux versions, en RECOMPOSANT les fichiers à l'aide de la chaine de changements enrgistrées dans le référentiel .git (c'est toute l'astuce de git).
Doc la question : comment utiliser Git en développement combiné à une exploitation effective du prototype de développement ?
Imaginons le scénario suivant : j'installe un Moodle 1.9 pour y développer mon composant. Je met mon composant sous Git . J'installe ma plate-forme, la fait tourner et met au point mon composant. Je veux faire la version 2.x, en supposant brancher... sauf que le reste du contexte est toujours en 1.9 (ainsi que la base de données de développement).
Là il me manque donc une case dans le tableau Git.... un truc que j'ai pas saisi...