OK
AJAX error!

Les forumsGrammalecteQuelle est la procédure pour procéder à des modification de code ?

Quelle est la procédure pour procéder à des modification de code ?

Bonjour,

J'aurais quelques propositions à faire sur des modifications de code (la partie JS) comment vous les faire ?
Je suppose qu'il faut :
* créer un compte sur code.grammalecte.net
* cloner le code
* ouvrir le repo fossil
* créer une branche (c'est à partir de là que je ne sais pas comment faire)
* poster les modifications de la branche

mais après je ne connais pas les commande de fossil, donc pouvez vous m'aider ?

Et sinon est-ce que nous devons parler avant sur le forum des modifications qu'on aimerait effectuer afin d'éviter de perdre du temps (aussi bien à coder que vous à relire le code) ?

Merci d'avance de votre réponse !
le 05 août 2017 à 13:24
Bonjour,

Oui, il faut :
— Créer un compte pour que je vous accorde des droits d’édition. (Ce qui est fait.)
— Cloner le dépôt en suivant les indications sur le wiki (en spécifiant son compte).
— Ouvrir le dépôt.

Ensuite, pour créer une branche, ça se fait en committant son code :
fossil commit -m "message" --branch branch_name

Si besoin, on peut aussi créer une branche après un commit avec :
fossil branch branch_name checkin_id

Les commandes les plus utiles sont :
fossil status --> indique où on est.
fossil changes --> les changements faits sur le check-out.
fossil diff --> voir le diff des changements faits.
fossil add file --> ajouter un fichier à la liste des fichiers suivis.
fossil extras --> liste les fichiers non suivis (exceptés ceux dans la liste d’exceptions).
fossil commit -m "message" --> committer les changements avec le message.
fossil sync --> se synchroniser avec le dépôt (surtout utile avant de faire des changements).
fossil checkout branch_name/checkin --> bascule de branche/checkin.
fossil update branch_name/checkin --> bascule de branche/checkin.

www.fossil-scm.org…

Et sinon est-ce que nous devons parler avant sur le forum des modifications qu'on aimerait effectuer afin d'éviter de perdre du temps (aussi bien à coder que vous à relire le code) ?


Ma foi, ça peut être utile. :)
le 06 août 2017 à 00:12

Veuillez m'excuser je m'étais tromper de branche de départ donc j'ai un peu polluer le timeline...


Pas grave.
Pour éviter ça, mieux vaut faire un `fossil diff` avant de commiter, pour voir les changements qui seront appliqués.
Et `fossil status` indique la branche où on est.

Au sujet des tags :
Si vous modifiez quelque chose dans :
— gc_core --> tag [core]
— gc_lang/fr --> tag [fr]
— gc_lang/fr/webext --> tag [fx]
— gc_lang/fr/xpi --> tag [fx]
— gc_lang/fr/tb --> tag [tb]
— make.py et compile_rules.py --> tag [build]
— cli.py --> tag [cli]
— server.py --> tag [server]
etc.

N’inventez pas de tag ou demandez.

Bon, il règne une certaine approximation quand on fait des changements sur plusieurs types de fichiers, mais essayez d’étiqueter selon la logique essentielle du commit. Merci.
Je trouve que ça rend l’historique plus facile à lire.

Enfin, essayez de faire attention à votre orthographe, sinon je corrigerai vos messages de commit et il n’existe pas de moyen que ça ne se voie pas. :)
le 06 août 2017 à 09:56
D'accord pour les tags.

Sinon pour les commits, il faut bien en faire 1 par type de changement comme j'ai essayé de faire ?

Pour les commentaires, j'avais hésité de les mettre en anglais (mais vu mon niveau dans cette langue, je les ai mis en français). Dans quelles langues préférez vous ?

Pour les noms de variable est-ce que vous suivez une convention ? si oui laquelle ?
le 06 août 2017 à 11:27

Sinon pour les commit il faut bien en faire 1 par type de changement comme j'ai essayé de faire ?


Oui, mieux vaut essayer de décomposer les modifications.
Je préfère que les modifs sur gc_core et gc_lang soient faites séparément, mais c’est plus une préférence qu’une règle. Parce que ce n’est pas toujours possible ou toujours évident à faire.
De même, mieux ne pas modifier xpi, webext et tb en même temps. Mais là encore, tout dépend du contexte.
Si possible, il faut modifier rules.grx à part, avec le tag [fr].

Pour les commentaire j'avais hésité de les mettre en anglais (mais vu mon niveau dans cette langue, je les ais mis en français) donc dans quelles langues préférez vous ?


Écrivez dans la langue qui vous convient le mieux.

Cela dit, pour ma part, j’écris en français pour tout ce qui concerne uniquement le français, c’est-à-dire ce qu’on trouve en général dans gc_lang/fr, et en anglais pour tout le reste (et parfois ce qu’on trouve dans gc_lang/fr si la logique dépasse le cadre français). Du moins, c’est la théorie.

Pour les nom de variable est-ce que vous suivez une convention ? si oui laquelle ?


snake_case pour les noms de module et les attributs HTML/CSS.
camelCase pour tout le reste, me semble-t-il.

Mais il reste du désordre, à cause de l’historique compliqué et des divergences de normes.

À l’origine, Grammalecte vient de Lightproof un module Python pour LibreOffice.
Python recommande le snake_case, tandis que LO utilise le camelCase prefixé façon notation hongroise : fr.wikipedia.org…
Par ailleurs, l’auteur de Lightproof utilisait beaucoup des variables de une lettre, genre a, s, m, n, etc., selon leur type.
Bref, Lightproof utilisait un mix de toutes sortes de variables.

Grammalecte a hérité de ça. Au début, j’ai utilisé le snake_case. Mais ça se combinait mal avec LO, je trouvais. Si j’ai longtemps utilisé des variables d’une lettre, selon leur type, j’ai maintenant arrêté et j’évite de le faire (sauf les fameux i, j des boucles). Mais il en reste pas mal.

Attendu que Python est pris entre l’étau de LibreOffice et JavaScript, qui utilisent tous les deux le camelCase, c’est camelCase pour le code JavaScript et Python.
Pour les noms de variables, Lightproof et LO m’ont poussé à utiliser les préfixes indiquant leur type. J’y ai pris goût.

Liste des préfixes usuels :

s --> string
c --> caractère
n --> nombre
i,j --> nombre indiquant un index
f --> nombre flottant
b --> booléen
by --> binary string (en Python)
z --> expression régulière
m --> résultat d’un test de regex (m pour match)
l --> liste, Array
a --> Array, liste
a --> set, frozenset, Set
d --> dictionnaire (ça peut aussi être un object JS avec uniquement des attributs servant de clés), Map
t --> tuples
sp --> string contenant un chemin
spf --> string contenant un chemin et un nom de fichier
sf --> string contenant un nom de fichier sans son chemin
h --> pointeur sur fichier (pour handle)
o --> objet
x --> objet “étranger”, objet LibreOffice, node HTML, en gros tout objet qui vient de l’extérieur.



Là où il y a le plus d’incohérences, c’est pour les variables globales, où je n’ai jamais trouvé une pratique qui me satisfait vraiment. Maintenant, j’évite les noms en toutes capitales, mais il en reste probablement.
le 06 août 2017 à 13:32
J’ai séparé la discussion sur JavaScript et la gestion du dépôt.
L’autre fil est ici : www.dicollecte.org…
le 06 août 2017 à 21:39
Vu qu'il faut au maximun séparer les modifications dans différents commits, je pense qu'il pourrait être intéressant de commencer les commentaires, par (!) quand on sait que les modifications du commit ne permettent pas de pouvoir faire fonctionner Grammalecte.
le 07 août 2017 à 15:50
Je vous arrête tout de suite.

Si un commit va casser quelque chose dans trunk, ne commitez pas.
Ça peut arriver bien sûr, mais ne le faites pas sciemment. Si vous avez cassé une chose involontairement, éditez le message du commit et ajouter le ! pour signaler le problème. Ce n’est pas une mauvaise idée.

Dans les branches initialisées par d’autres, de mon point de vue, ce n’est pas beaucoup plus tolérable. Évitez de casser sciemment ce sur quoi d’autres bossent.

Là, je viens de passer des heures à pêcher dans la doc de Mozilla et je reviens bredouille, ce qui a tendance à me rendre de mauvaise humeur. Alors si en plus quelqu’un rend ma branche dysfonctionnelle, je vais frôler la crise de nerfs. :)

Mais dans vos branches, c’est comme vous voulez.

Vu qu'il faut au maximun séparer les modifications dans différents commits


N’exagérons pas. Disons qu’il faut éviter si possible de mélanger les chèvres et les choux, mais je suis aussi partisan d’un minimum de souplesse.
le 07 août 2017 à 17:47
En fait, j'ai dû mal m'exprimer ou trop simplifié ma demande ;) Je vais essayer de m'expliquer.
Donc en fait, par exemple, on fait une grosse modification qui fait qu'il y a des modifications un peu partout.

Donc personnellement j’aurais préparé toutes les modifications et testé mais avec toutes les modifications.

Pour des raison de lisibilité et pour pouvoir facilement vérifier le code je pense qu'il faut commiter par répertoire, donc j'appliquerai localement les modifications sur un répertoire puis je ferai un commit, puis j’appliquerai la suite des modifs et un nouveau commit ainsi de suite. Donc normalement vu que de mon côté tout est préparé, mais c'est juste pour une question de timeline. Pour les différents commits il ne devrait pas y avoir longtemps entre le premier et le dernier. Mais les autres savent grâce au symbole dans le commentaire qu'il faut attendre un peu avant de tester le code et qu'il vaux mieux attendre un peu avant de partir sur une branche basée sur celle-là ou merger dans une autre branche.

C'est pour éviter de faire un gros commit !!!

Je pense que je ne vais jamais faire de commit sur le trunk. je préfère casser une branche perso afin que le code puisse être vérifié ;) D'ailleurs si d'autres personnes se mettent à faire des changements, je pense qu'il est important de signaler qu'il n'y a que vous qui touchez au trunk et que chacun doit travailler dans des branches persos.
le 07 août 2017 à 20:38
OK.
Dans ce cas, si c’est ce que vous voulez, il peut être intéressant de désactiver l’autosynchronisation du code avec le dépôt.

Pour faire ça, tapez :
fossil unset autosync

Ou bien, si vous voulez toujours avoir des pull automatiques :
fossil settings autosync pullonly

Pour réactiver l’autosync :
fossil settings autosync on
le 08 août 2017 à 07:50
Question bête comment on commit avec plusieurs tags ?
car j'avais essayer un

fossil commit -m "comment" --tag core js


ça fonctionnait pas heureusement ça n'a pas posté ;)

puis un

fossil commit -m "comment" --tag "core js"


mais ça avais créer un nouveau tag "core js" donc obliger de faire une action a posteriori

et j'aimerais bien ne plus mettre du tout de bazars dans le timeline :s
le 08 août 2017 à 22:28
Il suffit de faire :

--tag xxx --tag yyy --tag zzz



Les tags sont listés ici : code.grammalecte.net…

Tu as dû remarquer que j’ai étiqueté core des commits qui touchent à des fichiers sur conj, mfsp ou phonet. Mais c’est parce que ça concernait tout ce merdier sur l’initialisation générale du système.

Tu remarqueras aussi que les tags sur libellés du commit et les tags enregistrés sur le commit ne correspondent pas forcément.

Par exemple, je peux écrire un libellé :
[core][fr][js] commentaire
en utilisant seulement l’option --tag core, parce que les deux autres tags sont accessoires.

Je n’utilise jamais l’option --tag py ou --tag js.

Je ne sais pas si tout ceci est bien clair pour toi… ni même si c’est bien logique.

Moi, je trouve ça seulement pratique quand je remonte le fil des commits pour savoir ce que j’ai fait.
L’intérêt des tags, c’est que tu peux cliquer sur eux pour filtrer les commits.
le 09 août 2017 à 07:57
ASTUCES
Tu peux renommer fossil en un fichier d’une seule lettre. Mon fossil.exe s’appelle f.exe (j’utilise Windows).

La commande commit possède un raccourci : ci
La commande checkout possède un raccourci : co

Chez moi, je tape donc seulement pour commiter :
f ci -m "message" --tag xxx

D’ailleurs, toutes les commandes de fossil peuvent être raccourcies tant qu’il n’y a aucune ambiguïté.

Par exemple, tu peux écrire :
fossil time au lieu de fossil timeline
fossil up au lieu de fossil update.

Toutes les commandes sont ici : code.grammalecte.net…

Tu peux aussi utiliser un raccourci des hashcodes des checkins. Tu n’es pas obligé de les taper en entier (heureusement).
Les cinq ou six premiers caractères suffisent en général (tant qu’il n’y a aucune ambiguïté).
le 09 août 2017 à 07:57
Merci pour tes précisions.

La page récapitulative de toutes les commandes je l'avais déjà trouvée. D’ailleurs, c'est grâce à elle que j'arrive à utiliser fossil, mais par exemple pour le coup des multi-tags, ce n'était pas précisé dans la doc (et j'avoue que je n'avais pas pensé qu'il pouvait y avoir plusieurs --tag ...)

Au début, j'étais un peu réticent à l'utilisation d'un nouveau scm, mais finalement fossil est sympa d'utilisation.

J'espère que maintenant je ne ferai plus d'erreurs dans les commandes de fossil.
le 09 août 2017 à 09:38

Notification par e-mail    0