Flujo de trabajo: uso de formatos de documentos binarios en Git sin bloqueos (pasar de subversion)

16

Somos una consultora de software con multitud de proyectos para diferentes clientes. Tradicionalmente usamos Subversion, pero actualmente estamos considerando mudarnos a Git.

Una parte importante de los documentos que producimos se comparte con nuestros clientes (requisitos, diseños globales, especificaciones de prueba, etc.), y usamos MS Office para producirlos. En Subversion, podríamos usar su función "Bloquear" para asegurarnos de que nadie estaba editando el mismo documento al mismo tiempo. En Git, no puedes hacer eso ya que por su naturaleza distribuida, git no tiene bloqueos.

Las cerraduras son realmente poco más que un mecanismo de comunicación, pero son muy efectivas.

Actualmente, nuestro código y los documentos orientados al cliente están típicamente en diferentes subcarpetas de un repositorio svn diferente. Al pasar a git, ¿qué recomendarías que hagamos? Veo un conjunto de opciones:

  1. Movimos los repositorios de svn a git 1-on-1. En lugar de usar bloqueos en los archivos de Office, hacemos lo que la gente sugiere y de alguna manera intentamos cambiar nuestro flujo de trabajo para solucionarlo. Esto podría estar funcionando en una rama en cualquier edición de documento, y fusionarlo en una revisión. Este enfoque se divide, por ejemplo, en hojas de Excel que contienen información de gestión de proyectos; son fácilmente editados por los miembros del equipo (y alentamos que esto se haga), pero no están sujetos a ningún proceso de revisión formal

  2. Usamos git para código y svn para documentos y gestión de proyectos. Esto tiene la desventaja de que ciertos documentos más de diseño no estarán "cerca" del código que especifica, lo que aumenta la posibilidad de que las personas se olviden de actualizarlos. Además, todos deben usar y comprender dos conjuntos de herramientas. Dicho esto, tal vez esta sea una gran oportunidad para pasar a herramientas de documentos basadas en texto (latex, markdown, HTML, lo que sea) para documentos de diseño que no estén orientados al cliente.

  3. Como 1, pero pirateamos un git lockcomando que hace lo que svn lock hace por nosotros (alternar el indicador de solo lectura de manera apropiada y sincronizarlo con un servidor de alguna manera).

No compro el argumento de que los bloqueos no funcionan en un DVCS porque el sistema incluso debería funcionar cuando estás completamente desconectado. Las cerraduras de SVN también pueden anularse; Son un mecanismo de comunicación . Sin algún tipo de conexión de red, no podrá hacer que su computadora se comunique mucho.

No podemos ser la única tienda que está muy contenta con cómo svn lockencaja en nuestro flujo de trabajo, ¿verdad?

¿Alguna idea o consejo?

Encontré /programming/119444/locking-binary-files-using-git-version-control-system pero la discusión es bastante técnica; Estoy buscando formas de resolver o evitar el problema práctico de dos miembros del equipo que editan el mismo archivo binario al mismo tiempo.

skrebbel
fuente
¿Podría aclarar cómo "comparte" sus documentos con los clientes? Espero que tengan acceso de solo lectura y que su equipo administre los cambios como resultado de las solicitudes de cambio de ellos. ¿Es eso correcto?
vaughandroid
2
Es posible que desee utilizar la herramienta de administración de activos (con función de bloqueo) en lugar de un VCS para manejar documentos binarios. Trabajé en un lugar que tenía imágenes de 2 GB och verificadas en SVN, lo que hizo que comprometer todo lo demás fuera muy lento. Después de mover todo eso a una carpeta bajo copia de seguridad, las cosas se volvieron más rápidas y fáciles de manejar.
Spoike
1
@Baqueta Por correo electrónico o en papel. El punto es que "¡Solo use texto para documentos!" No es un enfoque razonable aquí, ya que el esfuerzo involucrado en hacer que se vea medio decente es mucho mayor que en herramientas como MS Word.
skrebbel
@Spoike, me parece una respuesta válida :-) De todos modos, ¿alguna recomendación?
skrebbel
@skrebbel Una palabra, LaTeX.
kyrias

Respuestas:

5

Le recomendaría que permanezca con SVN para los documentos de MS Office por dos razones:

  1. Ya está allí y es (en mi opinión) mejor para guardar documentos de Office (mira aquí ). Tiene muchas más herramientas de terceros para hacer esto.
  2. El bloqueo, aunque se puede lograr en Git, no es "el tipo de Git de hacer las cosas". Si necesita estas características, quédese con la herramienta que le brinda la mejor solución.

Hay un dicho que me gusta que dice algo como esto: "Cuando estás sosteniendo un martillo, todo parece un clavo". El hecho de que se esté mudando a Git para guardar su código, no significa que deba usarlo para guardar sus documentos.

Yoel Gluschnaider
fuente
¿Qué pasa si el código y los documentos están en el mismo repositorio SVN?
Jimmy T.
2

El control de versiones de código no es la mejor herramienta para trabajar en archivos de Office, porque son binarios y estas herramientas funcionan en la modificación a nivel de archivo.

Use una herramienta de colaboración, como MediaWiki (gratis) o Atlassian Confluence (de pago), desde la cual puede extraer fácilmente documentos de Word. O use LaTex para generar los archivos de Office.

Déjame expandir ...

Si necesita colaborar, debe adoptar un modelo que resalte las modificaciones (por ejemplo, cambiar una palabra, reformular o simplemente cambiar una fuente) a una unidad, por ejemplo, un archivo.

SVN y Git, incluso si se piensa en código, son herramientas de bajo nivel que comparan sus archivos por contenido textual. Pero el problema es que solo pueden funcionar en archivos de texto, porque no les importa la naturaleza / contenido del archivo para extraer un modelo de modificaciones de alto nivel.

Un claro ejemplo es un archivo de imagen . Aunque TortoiseMerge es una herramienta que ayuda a los usuarios de SVN mediante la comparación de las imágenes para sus modificaciones reales, lo normal VCSes ejecutar parches de contenido sobre los archivos. Dejame explicar. Una herramienta como TortoiseMerge puede decirle que una nueva versión de un archivo de imagen se cambia solo por unos pocos píxeles o luminancia si implementa un análisis HSV más complejo de los dos archivos. Puede añadir una marca de agua o cambiar color niveles, una herramienta que compara los archivos de imagen serán resaltar que las diferencias si se implementa buen algoritmo de comparación. Pero para verificar el nuevo archivo en su cliente debeproducir un delta. Un delta es un conjunto de líneas que se eliminan y líneas que se agregan al archivo. Los archivos binarios tienen ningún salto de línea si no suceda tener \r\n, o similares, en su carga útil, y en un delta si cambia un solo carácter está sustituyendo una línea entera.

Así que aquí está el problema. Los archivos binarios no son buenos para el control de versiones porque casi podría reemplazar el archivo completo para cada revisión. Considere cuando escribe archivos de Office usando MS Office y las ediciones de su colaborador con OpenOffice. Si implementan incluso una versión ligeramente diferente del algoritmo de compresión de los archivos OpenXML, terminará en archivos completamente diferentes, incluso si cambió una sola coma en el documento.

Los softwares de colaboración procesan documentos internamente en un formato basado en texto, porque el texto es lo realmente significativo para su empresa y puede calcular las diferencias o manejar conflictos. LaTex, o Markdown si lo desea, es una forma de almacenar un documento como un archivo de texto con marcado avanzado, por lo que no es como el archivo TXT clásico que no tiene control de fuente / formato.

Pero, obviamente, a sus clientes no les gustaría abrir archivos de Markdown, ¿verdad? Ok, puedes simplemente, y realmente quiero decir simplemente, usar cualquier software que actualmente sea demasiado flojo para google para convertir un documento fuente a PDF, Word o lo que sea.

Resumiendo

Si comienza a registrar archivos de texto en su control de origen, tiene un mayor control sobre el historial de archivos y puede manejar fácilmente los conflictos, especialmente sin usar bloqueos VCS.

Antes de compartir un documento oficialmente, necesita una rutina para exportar el documento de texto fuente a un archivo de Office

La separación de los dos pasos hace felices a las personas a costa de una curva de aprendizaje.

usr-local-ΕΨΗΕΛΩΝ
fuente
Los archivos de texto de Linux y Mac tampoco tienen líneas según su definición :-) se pueden crear deltas para archivos binarios con la misma facilidad. Usted decide sobre un algoritmo diferente. SVN, por ejemplo, crea agradables y pequeños deltas muy bien para archivos binarios (al menos con archivos .dll grandes con los que tengo más experiencia)
gbjbaanb
Sí, por supuesto, no Windows tiene terminadores de línea diferentes. De todos modos, incluso si logras crear un delta más pequeño (tendré que reformular un poco la respuesta), ¿hace que las diferencias sean legibles para los humanos? Por supuesto no. No dirá qué clases se han modificado entre las DLL. Y nuevamente, el problema es que dos compiladores pueden (dije que pueden ) producir archivos completamente diferentes al reordenar las clases de la manera que deseen. Ese fue el punto de la respuesta
usr-local-ΕΨΗΕΛΩΝ
-1

Puede usar git para esos documentos sin agregar bloqueo. Elija un flujo de trabajo git que bloquee los empujes a la rama maestra si no está en el maestro. (Hay varios flujos de trabajo para elegir). Esto evitará que las personas sobrescriban las modificaciones de los demás en los archivos de documentos binarios. Suponga que dos personas modifican el mismo documento binario. El primero que lo empuja a master recibe sus cambios. El segundo se bloquea porque su copia está detrás de la rama master. Tienen que sincronizar primero. Entonces la segunda persona se sincroniza. Mostrará un conflicto de fusión para el documento binario. Esa persona guarda su versión en algún lugar y resuelve el conflicto tomando la versión del maestro (que fue empujada por la primera persona). En este punto, los archivos de la segunda persona están actualizados con la rama maestra. Se fusionan en sus cambios al último documento binario (a mano), que luego contendrá los cambios de la primera persona y de la segunda persona. Luego, la nueva versión se empuja al maestro y se convierte en la nueva rama maestra. La fusión es un dolor, pero solo ocurre cuando hay un conflicto. Además, los cambios no se pierden ni se sobrescriben. Se detectan los conflictos y los usuarios pueden resolverlos limpiamente.

Nani Tatiana Isobel
fuente
44
Exactamente este dolor de fusión es lo que se supone que previenen las cerraduras.
oefe
De hecho, hay herramientas de combinación que pueden combinar documentos de Word. Sin embargo, no tengo experiencia con ellos, entonces, ¿qué tan buenos son?
Pete
Gracias por tu respuesta. Veo que esta es la forma de trabajar de Git. @Pete, Word en sí puede hacer un Diff bastante decente, no estoy seguro acerca de la fusión Pero aún así, es un dolor que se evita más fácilmente con las cerraduras. Raramente editamos documentos de Office simultáneamente; La mayor parte de nuestro trabajo (incluyendo documentos detallados) está en el código. Esta pregunta es sobre el 2% de los casos en los que 2 personas hacen editar el mismo documento al mismo tiempo. Dado que es del 2%, no del 30%, una solución de fusión se siente subóptima.
skrebbel
-2

Pon tus 2 primeras soluciones juntas y no necesitas una tercera.

Si guarda sus hojas de cálculo en el disco como CSV, Excel aún las editará y luego git estará encantado de fusionarlas por usted.

Del mismo modo, puede abrir, editar y guardar sus archivos en Word si son HTML o (que Dios nos ayude) RTF. Word, por supuesto, agregará más hinchazón que texto útil, pero sigue siendo solo texto que git está feliz de combinar para usted.

Por supuesto, estas soluciones suponen que no hace uso o puede alejarse de las funciones específicas de MS, lo que en realidad solo es un problema en el lado de Excel.

A menos que, por supuesto, también requiera que Word se instale en un sistema para poder leer su documentación, lo cual es en sí mismo una perspectiva aterradora para mí ...

Steven
fuente
1
De Verdad? ¿Sugiere volver a la edad de piedra para evitar conflictos de fusión?
Petter Nordlander
No estoy seguro de entender qué es exactamente lo que sientes es la edad de piedra sobre el almacenamiento en formato de texto versus formato binario ...
Steven