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

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

Bonjour Denis,

On 16/03/2015 11:30, D. Barbier wrote:
[...]
>> Si www devient un dépôt
>> Git, est-ce qu'on ne pourrait pas aussi y accéder par rsync ? Cela
>> suppose qu'il y aurait un répertoire de travail sur Savannah, pas juste
>> un dépôt nu.
>> - Sur le client, les anciennes versions seraient simplement remplacées
>> par les nouvelles, mais comme en principe on ne modifie pas les fichiers
>> dans www ça ne poserait pas de problème.
>> - Sur le serveur, un script commiterait automatiquement les fichiers
>> envoyés par rsync. La difficulté est qu'il faudrait envoyer le message
>> de commit avec les fichiers modifiés. Le plus pratique, pour éviter
>> erreurs et oublis, serait peut-être une interface web avec une zone de
>> saisie pour écrire le message. Peut-être aussi que ça faciliterait le
>> recrutement des coordinateurs.
> 
> Si 2 personnes modifient la même page, une des modifications est
> silencieusement écrasée. C'est le problème que résoud un VCS (Version
> Control System), passer outre n'est pas une bonne idée.

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.

> Je crois qu'il faut surtout déterminer les causes de la taille de www,
> et agir en conséquence. Si c'est à cause de l'historique, on peut
> regarder du côté de git shallow-clone. Si c'est à cause du nombre de
> langues, on en revient à la question de séparer le contenu par langue.
> Je n'ai toujours pas de solution miracle,  mais j'ai l'impression
> qu'il faudrait découper le dépôt de manière logique, aujourd'hui tout
> est mis dans le même sac.
> Cette séparation pourrait se faire soit avec des répertoires, soit
> avec des branches.
> 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. 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.

> 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.

 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.

Thérèse

[0] https://lists.gnu.org/mailman/private/www-discuss/2015/009141.html
[1] http://blogs.atlassian.com/2014/05/handle-big-repositories-git/