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

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

Bonjour Denis, bonjour à tous,

On 23/03/2015 11:34, D. Barbier wrote:
[...]
> Il faut que les traducteurs qui en ont envie travaillent
> comme ils veulent, sans utiliser ton script. Et c'est à toi de le
> prendre en compte ; toutes les questions que je pose se ramènent à ça,
> comment réagit ton système quand il y a un grain de sable ?

Les gens qui veulent travailler comme d'habitude ont une branche master
tout à fait normale, mais il y a une autre branche avec un répertoire de
travail. Le post-receive s'occupe de les aligner en temps réel.

[...] 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 ?
> 
> Je ne peux pas te répondre, puisque je ne sais pas comment est fait le
> cherry-pick. J'aurais tendance à penser comme toi que ça ne devrait
> pas arriver, mais ça m'étonnerait que ça n'arrive jamais. Par exemple,
> il suffit que les fichiers PO soient reformatés par gettext pour
> engendrer des conflits.

Dans ce cas-là, le pre-receive refuse les commits de la branche réduite
(simplement identifiée par son nom, *-nomerge par exemple), avec
explication dans le message d'erreur envoyé sur le terminal. Il faut
resynchroniser le dépôt local mais les modifs sont récupérables dans la
sauvegarde de rsync ou dans www-lang.

Après avoir un peu tâtonné, je trouve que le plus simple est de chercher
dans les 20 derniers commits de la branche réduite une correspondance
(diff vide) avec le haut de la branche master/gnun. C'est peut-être un
peu trop restrictif, mais plus rapide que de faire des diffs sur chaque
fichier.

Dès que les modifs sont enregistrées dans les logs, elles sont détectées
par inotifywait et picorées*. Pour qu'il y ait conflit, il faudrait que
les POs reformatés se pointent dans l'intervalle de temps entre la
réception des modifs et le début du picorage, soit nettement moins d'une
seconde. Et si ça arrive, j'imagine qu'un fichier .lock sera créé
quelque part (inotifywait en détecte plusieurs) et empêchera le
picorage. En admettant même qu'un picorage problématique ait lieu après
réception des POs formatés, il avortera et la branche réduite retournera
à l'état initial. Les messages d'erreur seront envoyés par email, comme
actuellement ceux de GNUN.

* Traduction trouvée dans git 1.9. Elle me plaît bien.  :)

Je pourrais d'ailleurs mettre tout au présent parce que le prototype
marche. La seule chose que je n'arrive pas à faire, c'est d'envoyer des
POs reformatés au bon moment pour créer un conflit.


>> De toute façon, l'envoi risque d'être refusé si on ne le fait pas.
> 
> C'est sûr, mais là tu parles de conflits dans la branche www-po, alors
> que je parlais de conflits dans master.
>
>> Et la précaution élémentaire, c'est
>> d'éviter le passage de GNUN (HH:57-HH:O2 et HH:27-HH:32).
> 
> Justement, c'est le genre de grain de sable dont je parle au début. Il
> faut que le système soit robuste, tu ne peux pas demander aux
> traducteurs ou coordinateurs d'éviter certaines plages horaires.

En fait ça ne devrait pas poser plus de problèmes que maintenant, voir
plus haut.

> 
> Denis


Voilà ce qu'il y a dans le prototype :

  - un pre-receive pour vérifier qu'il ne risque pas d'y avoir de
conflits de picorage sur les branches réduites et que les fichiers sont
valides (il détecte les erreurs HTML dans les msgstr sans utiliser PO4A) ;
  - un post-receive pour synchroniser le répertoire de travail du
serveur avec master ;
  - un script qui attend tapi dans l'ombre ; il détecte les modifs sur
les branches réduites, les picore, remet tout en ordre si ça se passe
mal et envoie les messages d'erreur ou la liste des fichiers modifiés
par courriel ;
  - un contrôleur, du style qu'on trouve dans /etc/init/, qui permet au
pre-receive de savoir si le script de picorage est actif et de le
démarrer au besoin.

Comme il n'y a pas urgence vu qu'il passera de l'eau sous le pont avant
que les webmestres se mettent d'accord pour passer à Git... ou non, je
ne mets pas le bébé en pj tout de suite. Mais si quelqu'un veut regarder
à quoi il ressemble, le critiquer, faire des améliorations, etc., je le
lui enverrai avec grand plaisir. Ou bien je peux le mettre sur la
branche scripts de www-fr.

Amicalement,
Thérèse