Git (ou Hg) plugin pour traiter des fichiers Microsoft Word et/ou OpenOffice

Que Diriez-vous de:

1. enregistrez votre mot docs en XML.
2. Valider votre XML des fichiers Word.

3. Diff à l'aide d'un XML outil de comparaison. Par exemple:

   $ git difftool -t xmldiff c3d293 498571

la transformation des fichiers XML en un élément par ligne devrait permettre d'exécuter efficacement le processus d'enregistrement et d'utiliser rapidement L'outil de diff XML externe.

, les Références:

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

une belle astuce que j'ai pu trouver qui fonctionne aussi sur les dossiers de bureau ouverts, PPTs, etc.:

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

voici une capture d'écran qui démontre le résultat:

si vous êtes sur MS Windows, utilisez TortoiseGit . J'ai juste eu à traverser cette expérience douloureuse, et TGit, même si inélégant prend une partie de la douleur. Quelques autres points:

• étonnamment git diff et gitk font tous deux un travail raisonnablement bon d'au moins visualisant diffs entre .docx (pas sûr à ce sujet .doc, mais je suppose que c'est la même chose). C'est bon pour juste un balayage rapide de diff lorsque vous faites s'engage.
• vous êtes complètement hors de chance en ce qui concerne fast forward et automerging est concerné. Malheureusement, je n'ai pas trouvé d'outil qui puisse gérer cela (bien que j'aime l'idée xml ci-dessus), donc vous devrez faire toutes les fusions manuellement.

• Microsoft Word (MS Word) a un outil de fusion décent, si défectueux. AFAIK, il ne peut faire que des fusions 2-way ( i.e.: X0 + dX = X1 ), pas des fusions 3-way ou 2-parent, qui sont plus fréquents dans le contrôle de version ( i.e.: X0 + dX1 + dX2 = X1 ). Vous pourrait résoudre les conflits de fusion en utilisant cet outil, mais il y aurait un peu de droit de legwork - vérifier chaque branche, exporter la tête comme une version non tracée, etc.

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

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

répondre à la question de JudoWill-Workshare est probablement l'outil de pointe utilisé par les avocats.

j'ai compilé des instructions pour plusieurs endroits ici: http://bit.ly/17LaxVY

# download docx2txt by Sandeep Kumar
wget -O docx2txt.pl http://www.cs.indiana.edu/~kinzler/home/binp/docx2txt

# make a wrapper 
echo '#!/bin/bash
docx2txt.pl  -' > docx2txt
chmod +x docx2txt

# make sure docx2txt.pl and docx2txt are your current PATH. Here's a guide
http://shapeshed.com/using_custom_shell_scripts_on_osx_or_linux/
mv docx2txt docx2txt.pl ~/bin/

# set .gitattributes (unfortunately I don't this can't be set by default, you have to create it for every project)
echo "*.docx diff=word" > .git/info/attributes

# add the following to ~/.gitconfig
[diff "word"]
    binary = true
    textconv = docx2txt

# add a new alias
[alias]
    wdiff = diff --color-words

# try it
git init

# create my_file.docx, add some content

git add my_file.docx

git ci -m "Initial commit"

# change something in my_file.docx

git wdiff my_file.docx

# awesome!

Il fonctionne très bien sur OSX

les cabinets d'avocats disposent de systèmes extrêmement robustes pour ce faire. Une personne qui ne fait pas confiance à l'historique de révision du document (parce qu'il est de source externe) et à la place font leurs propres comparaisons et peuvent fournir des deltas. Si c'est ce dont ils ont vraiment besoin, tu es mieux d'acheter ça que de mettre un papier dans git ou mercurial qui ne sera jamais vraiment utilisable pour eux.

Désolé d'avoir l'air pessimiste, mais il est plus probable que les techniciens utiliseront (alors que grommeling) l'outil commercial hors de prix qu'il est que les gens de bureau vont utiliser git ou mercurial à tout niveau de satisfaction.

en utilisant svn (pas git ou hg, mais vous pourriez avoir une passerelle), il y a une extension pour Ooo travaillant sur des fichiers XML non compressé, voir ma réponse à propos d'une question similaire. BTW, si ever vous regardez le code du plugin et le faites HG-aware au lieu de svn, s'il vous plaît faites le moi savoir! ;- )

git 1.6.1 ou plus vient maintenant avec les caractéristiques textconv , qui permet d'utiliser une commande arbitraire pour convertir un fichier en texte avant de diffuser.

vérifiez aussi: https://gist.github.com/17twenty/4985374