Accéder au contenu.
Menu Sympa

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

Objet : Liste de travail pour la traduction de la philosophie GNU (liste à inscription publique)

Archives de la liste

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


Chronologique Discussions 
  • From: "D. Barbier" <bouzim AT gmail.com>
  • To: "trad-gnu AT april.org" <trad-gnu AT april.org>
  • Subject: Re: [Trad Gnu] Migration de www vers un autre VCS : Git ?? Bazaar ?
  • Date: Mon, 16 Mar 2015 13:05:19 +0100

Le 16 mars 2015 12:32, Thérèse Godefroy a écrit :
[...]
> Quand un fichier est envoyé dans le répertoire de travail www du serveur
> (par rsync ou autre), est-ce que le script ne pourrait pas créer un
> fichier .lock qui empêcherait quelqu'un d'autre de pousser/uploader le
> même fichier en même temps ? C'est déjà ce qui se passe avec GNUN par
> moment. Le .lock serait effacé après addition et commit du fichier
> envoyé par rsync. Je suppose que cette opération peut se faire en
> quelques secondes si add/commit est déclenché par la réception du
> fichier plutôt que par une tâche programmée.

Pour GNUN, je n'ai pas regardé en détail, mais je pense que c'est pour
éviter que le même script modifie les fichiers alors qu'une autre
instance est déjà en train de le faire. Ce que tu veux faire est plus
compliqué, il faut empêcher des personnes différentes de modifier le
même fichier. Honnêtement, tu auras du mal à convaincre que c'est
jouable, il vaut mieux se reposer sur un VCS pour garantir la
non-concurrence des modifications, ces programmes sont prévus pour ça.

[...]
>> Dans le dépôt, on a actuellement :
>> 1. les pages HTML originales
>> 2. les autres fichiers originaux (images, etc)
>> 3. les fichiers PO
>> 4. les fichiers HTML générés par po4a
>> Les coordinateurs des équipes de traduction ont besoin de 1 et 3 (et
>> parfois 2),
>
> Oui, mais ils n'ont pas besoin des fichiers PO de toutes les langues.

Si, pour corriger les erreurs de syntaxe (PO ou HTML) dans les fichiers PO.

> On
> peut faire la sélection avec CVS, mais je ne vois pas comment la faire
> avec Git si tous les POs sont dans un même dossier, mélangés avec *pot,
> *translist, *.lang-en.html, *.lang-diff.html et peut-être encore d'autres.

Oui, c'est ce que je dis, il faut commencer par séparer le contenu en
fonction de l'utilisation qui en est faite. Cette séparation peut être
faite par répertoire, en réorganisant tout, mais une autre possibilité
est de le faire par branches en conservant l'arborescence actuelle,
par exemple ainsi :
- une branche html contiendrait les pages HTML en anglais
- une branche static contiendrait les images, etc
- une branche po-XX par langue (avec XX le code de langue) ne
contenant que les fichiers XX.po
- une branche website contenant tout
Les branches html et static ne contiennent que des commits normaux
faits par les webmestres. Les branches po-XX contiennent des merges de
html et static, et les commits des traductions. La branche website ne
contient que des merges de html, static et de toutes les branches
po-XX, son contenu serait donc identique à ce qu'il y a actuellement
dans www. Ça me semble faisable. Il faut ensuite voir s'il est
possible de merger html dans po-XX sans avoir besoin de tout le dépôt.

>> les traducteurs ont besoin de 3 (qui est l'équivalent du
>> www-fr actuel), les webmestres ont besoin d'avoir accès à tout.
>
> Ils ont quelquefois besoin d'avoir accès à l'historique, mais pas
> nécessairement sur la branche principale. Si on met l'historique CVS sur
> une branche différente, on a le choix de la cloner, ou pas.

Je pense que c'est là un sujet d'incompréhension entre nous. Pour moi,
l'historique de CVS n'est pas un problème spécifique. Si on passe à
git, il faut se projeter dans 5 ans, on aura accumulé un certain
nombre de commits supplémentaires, il faut qu'on soit capable de les
supporter.

> Suite
>> des réflexions plus tard, il faut que ça mûrisse ;-)
>>
>> Denis
>>
> Tu sais quoi ? Tes réflexions compléteraient agréablement un nouveau fil
> sur www-discuss [0] que j'espère plus productif que le précédent.
> Il y a en particulier une référence indiquée par Dave sur la gestion des
> gros dépôt Git [1]. Il semble que les versions récentes de Git
> autorisent pull et push pour les clones avec très peu d'historique.

Oui, j'ai vu, pour l'instant je ne sais pas trop comment intervenir,
j'attends le bon moment tapi dans l'ombre ;-)

Denis



Archives gérées par MHonArc 2.6.18.

Haut de le page