Ét.Nadji.fr/

Du code, des mots, des livres.

Synchronisation du travail sous Métopes via Git

10/02/2019 à 20h
Remarque:
Si vous ne savez pas ce qu’est Métopes, cet article n’a aucun intérêt pour vous.

Abréviations employées

UE (pluriel : UEs)
abrège « Unité éditoriale »

Lorsqu’on travaille sur un texte à plusieurs, et / ou à fortiori, sur le même texte sous des formes différentes, la question de la synchronisation se pose tôt ou tard  il s’y greffe rapidement un problème, celui du conflit de modification de fichiers.

«  J’ai corrigé cela mais entretemps, X a travaillé sur la version Bidule1, donc je vais devoir reporter mes modifications sur la version à jour…  »
«  En fait, l’auteur a fait marche arrière, donc il faudrait rétablir telle norme, sans pour autant annuler les modifications postérieures à l’application de la norme remplacée.  »

Et ainsi de suite. Autant de situations qui sans le bon outillage et sans réflexion préalable vous font perdre du temps et vous donnent envie d’aller vous pendre au fond des bois du calme2.

On peut résoudre une bonne part de ces problèmes en utilisant un logiciel de gestion de versions, le plus connu étant Git (on peut également citer Mercurial ou Subversion). Comme le titre de billet l’indique, c’est de Git dont je vais parler.

Remarque:
Je ferais peut-être un billet pour présenter Git aux littéraires. On verra.

Mais encore faut-il trouver une organisation des dépôts qui soit pratique et compatible avec les impératifs d’organisation liées à Métopes.

Sommaire

  1. Séparation minimale : Éditorial, Métopes
    1. Automatisation de la séparation minimale
  2. Séparation étendue : Éditorial, Iconographie, Métopes
  3. Des sous-modules partout ?
  4. Après l’organisation

Séparation minimale : Éditorial, Métopes

On peut organiser un dossier nommé Éditorial de la façon suivante.

Il faut d’abord un dossier servant d’archives aux textes tels que fournis par l’auteur, et un dossier consacré à l’archivage des conversations entre la personne chargée de la préparation de copie et l’auteur.

Dans un monde idéal, l’auteur fournirait au préparateur de copie un tapuscrit3 propre. On pourrait donc passer directement à la correction, et à l’application sommaire des styles Métopes, que ça soit fait dès le départ.

Sauf qu’évidemment, on n’est pas dans un monde idéal, et les auteurs sont très inégalement à l’aise avec un traitement de texte4. On retrouve les erreurs classiques :

Et ainsi de suite. Il nous faut donc en plus un espace où l’on conservera les versions « nettoyées », qui serviront de base à la préparation de copie en elle-même. Pour ce qui de la manière de nettoyer le fichier, la séquence Docx → Markdown → Docx via Pandoc est une bonne base.

À partir des fichiers nettoyés, on peut entamer la préparation de copie, dans des styles de traitement de texte qui sont ceux de Métopes (il n’y a pas de raison particulière de les appliquer lors d’une étape postérieure).

Voilà pour la partie « éditoriale » — quoi qu’on puisse dire que certaines activités sous XMLmind relèvent de l’éditorial. Il me semble qu’il est pertinent séparer le travail surtout éditorial de la préparation de copie du travail d’édition structurée via Métopes. Le dossier type de Métopes est donc à part.

On obtient donc deux dossiers avec ce genre d’arborescences :

Arborescence de deux dossier, un consacré à l’éditorial, l’autre adoptant la structure type d’un ouvrage sous Métopes.
Fig. 1 – Arborescence des dossiers Éditorial et Métopes

À présent, comment synchroniser avec Git ces dossiers ? D’abord en faisant d’Éditorial et de Métopes deux dépôts distincts. On part du principe que les unités éditoriales stylées sont à la racine du dépôt, et les trois dossiers sont ignorés via le fichier .gitignore.

Afin que les UEs stylées soient synchronisées dans Métopes/edito, on fait d’Éditorial un sous-module de Métopes. Cela évitera de polluer l’historique de Métopes avec celui d’Éditorial.

Fig. 2 – Même arborescence, comme des dépôts Git.

Avec une telle configuration, la part de préparation de copie peut être faite indépendamment de la transformation en XML / TEI, et quand même demeurer à jour.

Remarque:
Oui, on peut modifier les UEs stylées de Métopes/styles, mais dans ce cas, il faut faire un commit dans Métopes/styles, faire un push et récupérer les modifications dans Éditorial via un pull.

Automatisation de la séparation minimale

Qui dit automatisation dit script. Git étant un logiciel d’abord et avant tout en ligne de commande, ça ne pose aucun problème :

#!/bin/bash

# Chemins absolus des dépôts locaux.
edito="Edito"
metopes="Métopes"

clear
cd $edito
git commit -a -v && git push origin master

cd $metopes

# Synchronisation des UEs stylées
cd styles
git pull
cd ..
# On commit les styles avant tout le reste pour avoir un historique
# propre.
git commit -v styles

# Commit du reste du dépôt Métopes
git commit -a -v

# On ne peut pas conditionner le push au commit précédent,
# parce que le commit des UEs stylés peut avoir été fait.
git push origin master

Séparation Éditorial / Iconographie / Métopes

On pourrait cependant synchroniser également l’iconographie de l’œuvre — je précise que l’iconographie est celle employée dans les figures et la première de couverture, pas celle possiblement employée dans la maquette papier.

Mêmes arborescences, mais sans notion de dépôt Git et avec un dossier Iconographie adoptant l’arborescence de Métopes/icono/
Fig. 3 – Idem, avec un dossier Iconographie adoptant l’arborescence de Métopes/icono/

C’est un fait connu que les graphistes ont tendance à employer des conventions de nommage de fichiers plutôt… relâchées, notamment parce qu’il n’est pas simple de gérer l’historique d’un fichier image autrement qu’en remarquant les changements du binaire — le SVG constituant une exception7.

Un exemple (caricatural) des conventions de nommage des graphistes.
Extrait de la conférence « Paginer le flux » de Julie BLANC, Lure, 2018.

Si l’on fait d’Iconographie un dépôt GIT, il faudra donc faire en sorte que Git ignore les fichiers intermédiaires. L’arborescence d’Iconographie reprenant celle de Métopes/icono/, seules les images validées et définitives devront aller dans hr, mr, br. On applique le même principe des sous-modules.

Idem, avec Iconographie étant un submodule de Métopes (dans Métopes/icono/).
Fig. 4 – Mêmes arborescences, comme des dépôts Git. Les fichiers intermédiaires d’Iconographie ne sont pas indexés.

Des sous-modules partout ?

Au stade où l’éditorial, le travail sous Métopes et l’iconographie sont séparés, on pourrait envisager d’ajouter deux sous-modules, un pour les unités éditoriales et les exports (dossier XML de Métopes) et un autre pour la mise en page via InDesign (dossier INDD de Métopes).

Mais ces sous-modules devraient être créés en cours du travail d’édition, et non dès le départ. Ils posent plus de problèmes de synchronisation qu’ils n’en résolvent.

Si des UEs nécessitent d’être réimportées dans InDesign, il n’y a pas de raison de les séparer du dossier Métopes, pour cloner au final le dépôt XML aileurs.

De plus, si on peut envisager que le sous-module XML permette de travailler à plusieurs sur le format structuré des UEs, il n’est pas certain que toutes les personnes en charge préfèrent faire leurs modifications dans XMLmind, plutôt que de les faire dans Word et les réimporter.

On pourrait à la rigueur, versionner, transformer en sous-module certains exports de Métopes, comme les ePubs (peut-être en créant des branches Git selon les diffuseurs numériques).

Après l’organisation

Que faire après appliqué une organisation en sous-module de ce genre ? Voici quelques idées, qui demandent à être testées :

Notes

  1. Alors que le boulot de Bidule est très bien #privateJoke.
  2. Je suis quelqu’un de calme. COMPRIS !?
  3. Généralement un fichier du logiciel de traitement de texte redmondien, de quoi faire douter qu’il s’agisse d’un monde idéal ☺. Mais même si c’était un fichier OpenDocument / LibreOffice, cela ne garantirait pas la propreté du fichier. Savoir écrire dans un traitement de texte n’équivaut pas à savoir bien s’en servir.
  4. Non, écrire en Markdown, en ReStructuredText ou en LaTeX n’est pas plus simple. Markdown est simple, mais pour quelqu’un qui comprend HTML.
  5. Y’a pas de raison que ce soient uniquement ceux qui n’ont jamais été formés aux traitements de texte qui fassent n’importe quoi.
  6. Quand un auteur n’emploie pas les styles (pourtant prédéfinis) qui servent structurer le texte, il faut avoir une table des matières, sans quoi on peut rater des titres. D’autant que l’économie de l’œuvre peut être un peu tordue.
  7. Le format SVG reposant sur XML, toute modification d’une image au format SVG équivaut à une modification de code XML identifiable, et donc exploitable par Git. Mais il reste assez difficile de comprendre le changement effectué sans message de commit.

Commentaires

Pour commenter ce billet, envoyez un mail sur etnadji (at) eml.cc, ou créez-vous votre blog.