Re: [Trad Gnu] Migration de www vers un autre VCS : Git ?? Bazaar ?

[Thérèse Godefroy <godef.th AT free.fr>]

On 20/03/2015 17:41, D. Barbier wrote:
> Le 19 mars 2015 17:37, Thérèse Godefroy <godef.th AT free.fr> a écrit :
>> On 19/03/2015 17:59, D. Barbier wrote:
[...]
>> Elles sont cherry-pickées à partir de master (la branche qui a le
>> répertoire de travail dans lequel travaille GNUN). Cela peut se faire
>> toutes les demi-heures juste avant que GNUN fasse son boulot, ou bien
>> chaque fois qu'une branche est modifiée (le post-receive pourrait
>> envoyer le signal).
> 
> Comment le script sait ce qu'il doit cherry-picker ? Il n'a aucune
> idée ce ce qui est sur les branches. Par exemple, admettons qu'un
> cherry-pick ait eu lieu. Tu rajoutes ensuite des commits dans la
> branche. Comment le script sait qu'il doit prendre les commits entre X
> et Y sur la branche ?

Il y a sûrement moyen d'utiliser inotify-tools [0] ou quelque chose
d'approchant. Je n'ai pas encore essayé mais ça ne saurait tarder.


>>>  2. Quand une erreur est commise dans un fichier PO (donc dans la
>>> « branche » de la langue correspondante), qui la corrige et où ?
>>
>>  Le script pre-receive devrait fonctionner pour toutes les "branches"
>> puisqu'elles utilisent toutes le répertoire .git du dépôt distant. J'ai
>> un prototype qui valide les POs avec msgcat et les HTML originaux avec
>> xmllint. Il refuse ceux qui ne passent pas l'inspection et renvoie les
>> messages d'erreurs sur la console de l'envoyeur.
> 
> Ok, les erreurs gettext sont effectivement faciles à attraper, mais je
> pensais aux erreurs de syntaxe HTML dans les traductions, qui ne
> surviennent que lorsqu'on fait mouliner po4a. Actuellement ce sont
> souvent les webmestres qui les corrigent.

C'est sûr qu'à moins de lancer GNUN à chaque commit on n'évitera pas les
erreurs HTML dans les traductions. Il y aura tout de même moins de
rapports d'erreur que maintenant. Il me semble qu'il y a ce genre
d'erreur parce que certains utilisent GNUN comme validateur. Pourtant il
y a un outil en ligne qui marche pas mal [1].

J'ai ajouté au prototype un truc qui vérifie qu'il y a la même version
de chaque fichier sur la branche locale et dans le répertoire de travail
du serveur avant modif (ou bien après). Il faut aussi que master
récupère les nouveaux commits immédiatement.


>> Pour les conflits de cherry-pick, je n'ai pas encore d'idée. Mais pour
>> qu'il y ait conflit sur master, il faudrait qu'il y ait plusieurs modifs
>> presque simultanées du même fichier sur des branches différentes.
> 
> Comme je ne comprends toujours pas, je ne peux pas répondre, mais il
> est sûr qu'on ne peut pas mettre en place un script automatique si on
> ne sait pas résoudre automatiquement les conflits.

Est-ce qu'il peut y avoir conflit si on synchronise la branche locale
avant de faire les mises à jour et qu'on la resynchronise après, juste
avant de pousser les modifs ? De toute façon, l'envoi risque d'être
refusé si on ne le fait pas. Et la précaution élémentaire, c'est
d'éviter le passage de GNUN (HH:57-HH:O2 et HH:27-HH:32).


Bon week-end,
Thérèse

[0] http://techarena51.com/index.php/inotify-tools-example/
[1] https://chapters.gnu.org/gnun/test.html