tipos tag remove practices etiquetas drop create best git version-control plugins mercurial openoffice.org

remove - git tags best practices



Complemento Git(o Hg) para tratar con archivos de Microsoft Word y/o OpenOffice (8)

Git 1.6.1 o posterior ahora viene con las características textconv , que permite usar un comando arbitrario para convertir un archivo a texto antes de la diferenciación.

mira esto también: https://gist.github.com/17twenty/4985374

¿Alguien ha encontrado un plugin Git o Hg para diffs / merging / branching "significativos" de archivos de Word de OpenOffice o Microsoft?

Sé que puedo "verificar" archivos .doc pero tanto Git como Hg los tratan como blobs binarios. Me gustaría poder hacer todas (o al menos muchas) de las operaciones basadas en revisiones normales en el texto del archivo.

Y sí, sé que debería usar Latex o convertir archivos de ida y vuelta entre RTF. Solo busco una solución más "nativa" ya que estoy tratando de gestionar la colaboración entre técnicos y "gerentes".

Esto está relacionado con mi pregunta sobre Biostar aquí: http://biostar.stackexchange.com/questions/1749/writing-collaboration-with-source-control-and-microsoft-word

Gracias.

Los bufetes de abogados tienen sistemas extremadamente robustos para hacer esto. Uno que no confía en el historial de revisión en el documento (porque es de origen externo) y en su lugar hace sus propias comparaciones y puede proporcionar deltas. Si eso es lo que realmente necesitan, es mejor comprarlo que poner un envoltorio en git o mercurial que nunca será realmente utilizable para ellos.

Perdón por sonar como pesimistas, pero es más probable que los expertos en tecnología usen (mientras se quejan) la herramienta comercial costosa de lo que es que la gente de la oficina usará git o mercurial para cualquier nivel de satisfacción.

Qué tal si:

  1. Guarde sus documentos de Word en XML.
  2. Confirme sus archivos de Word XML.

  3. Difícil usando una herramienta externa XML diff. Por ejemplo:

    $ git difftool -t xmldiff c3d293 498571

La transformación de los archivos XML para tener un elemento por línea debería hacer que el proceso de check-in se ejecute de manera eficiente y también permitir que la herramienta XML diff externa se procese rápidamente.

Referencias

Recopilé instrucciones para varios lugares aquí: 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 $1 -'' > 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!

Funciona muy bien en OSX

Respondiendo a la pregunta de JudoWill: Workshare es probablemente la herramienta líder utilizada por los abogados.

Si está en MS Windows, use TortoiseGit . Simplemente tuve que pasar por esta experiencia dolorosa, y TGit, aunque poco elegante, le quita parte del dolor. Un par de otros puntos:

  • Sorprendentemente, git diff y gitk hacen un trabajo razonablemente bueno al menos al visualizar diferencias entre .docx (no estoy seguro acerca de .doc, pero supongo que es lo mismo). Esto es bueno solo para un escaneo rápido de diffs al hacer commits.
  • Estás completamente fuera de suerte en lo que respecta al avance rápido y la automatización. Lamentablemente, no he encontrado una herramienta que pueda manejar esto (aunque me gusta la idea xml anterior), por lo que tendrá que hacer todas las fusiones manualmente.

  • Microsoft Word (MS Word) tiene una herramienta de fusión decente, aunque defectuosa. AFAIK, solo puede hacer fusiones de 2 vías ( es decir: X0 + dX = X1 ), no fusiones de 3 o 2 padres, que son más comunes en el control de versiones ( es decir: X0 + dX1 + dX2 = X1 ). Podrías resolver los conflictos de fusión usando esta herramienta, pero habría un cierto trabajo de campo: revisando cada rama, exportando HEAD como una versión sin seguimiento, etc.

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

  • Afortunadamente esto es exactamente lo que hacen TGit (y TSVN también). Desgraciadamente, evitaría la rebase ya que si tienes que repetir varios cambios seguidos, puede ser muy agotador, pero merge documentos cortos está bien, pero no es genial.

Usando svn (no git o hg, pero podría tener una puerta de enlace), hay una extensión para Ooo trabajando en archivos XML sin comprimir, vea mi respuesta sobre una pregunta similar. Por cierto, si alguna vez miras el código del complemento y lo haces hg-aware en lugar de svn, ¡házmelo saber! ;-)