Plugin Git (ou Hg) pour le traitement des fichiers Microsoft Word et/ou OpenOffice

Question

Est-ce que quelqu'un a rencontré un plugin Git ou Hg pour des diffs/merging/branching "significatifs" de fichiers OpenOffice ou Microsoft word.

Je sais que je peux "archiver" des fichiers .doc mais Git et Hg les traitent comme des blobs binaires. J'aimerais pouvoir faire toutes (ou du moins beaucoup) d'opérations normales basées sur la révision sur le texte du fichier.

Et oui, je sais que je devrais utiliser Latex ou convertir des fichiers en RTF. Je cherche simplement une solution plus "native" car j'essaie de gérer la collaboration entre les techniciens et les "gestionnaires".

Ceci est lié à ma question sur Biostar ici : http://biostar.stackexchange.com/questions/1749/writing-collaboration-with-source-control-and-microsoft-word

Merci.

Answer 1

Pourquoi pas :

1. Enregistrez vos documents Word en XML.
2. Sauvegardez vos fichiers Word XML.

3. Diffusion à l'aide d'un outil de diffusion XML externe. Par exemple :

   $ git difftool -t xmldiff c3d293 498571

La transformation des fichiers XML pour qu'ils comportent un élément par ligne devrait permettre au processus d'enregistrement de se dérouler efficacement et à l'outil de comparaison XML externe de fonctionner rapidement.

Références :

• http://www.kernel.org/pub/software/scm/git/docs/git-difftool.html
• http://www.logilab.org/projects/xmldiff

Answer 2

J'ai trouvé une astuce qui fonctionne également avec les fichiers Open Office, les PPT, etc :

http://xcafebabe.blogspot.hu/2012/09/sexy-comparison-of-word-documents-with.html

Voici une capture d'écran qui illustre le résultat :

Answer 3

Si vous êtes sous MS Windows, utilisez TortoiseGit . J'ai simplement dû passer par cette expérience douloureuse, et TGit, bien qu'inélégant, enlève une partie de la douleur. Quelques autres points :

• Étonnamment, git diff et gitk font tous deux un assez bon travail pour au moins visualisation de les différences entre les .docx (je ne suis pas sûr pour les .doc, mais je suppose que c'est la même chose). C'est une bonne chose pour un examen rapide des différences lors des commits.

• Vous n'avez aucune chance en ce qui concerne l'avance rapide et l'automatisation. Malheureusement, je n'ai pas trouvé d'outil capable de gérer cela (bien que j'aime l'idée du xml ci-dessus), vous devrez donc effectuer toutes les fusions manuellement.

• Microsoft Word (MS Word) dispose d'un outil de fusion décent, bien qu'imparfait. A priori, il ne peut faire que des fusions à deux voies ( c'est-à-dire : X0 + dX = X1 ), et non les fusions à 3 ou 2 parents, qui sont plus courantes dans le contrôle de version ( c'est-à-dire : X0 + dX1 + dX2 = X1 ). Vous pourrait résoudre les conflits de fusion à l'aide de cet outil, mais il faudrait faire un travail de fond - vérifier chaque branche, exporter HEAD comme une version non suivie, etc.

  X0 = *.BASE.docx,
  X0 + dX1 = *.LOCAL.docx and
  X0 + dX2 = *.REMOTE.docx

• Heureusement, c'est exactement ce que fait TGit (et TSVN aussi). Je voudrais malheureusement éviter rebase car si vous devez rejouer plusieurs changements d'affilée, cela peut être très fatigant, mais merge pour les documents courts, c'est bien, mais pas génial.

Answer 4

Pour répondre à la question de JudoWill - Workshare est probablement le principal outil utilisé par les avocats.

Answer 5

Les cabinets d'avocats disposent de systèmes extrêmement robustes pour ce faire. Ils ne se fient pas à l'historique des révisions du document (parce qu'il provient d'une source externe), mais effectuent leurs propres comparaisons et peuvent fournir des deltas. Si c'est ce dont ils ont vraiment besoin, il est préférable d'acheter ce système plutôt que de mettre une enveloppe dans git ou mercurial qui ne sera jamais vraiment utilisable pour eux.

Désolé de passer pour un pessimiste, mais il est plus probable que les techniciens utilisent (tout en râlant) l'outil commercial hors de prix que les employés de bureau utilisent git ou mercurial de manière satisfaisante.