¿Control de versiones para colaboración (con diferencias de nivel de palabra)?

20

La mayoría de los documentos ahora se escriben en colaboración, y los colaboradores a menudo se encuentran en diferentes lugares. Siempre he usado sistemas de control de versiones para mis documentos y código, y también he encontrado que el control de versiones es crítico para proyectos de software colaborativos, pero parece que muchos investigadores en teoría evitan su uso para escribir documentos conjuntos. Para convencer a mis colaboradores de que el control de versiones (control de revisión) es una buena idea para trabajar juntos, parece que hay algunos requisitos previos. No es posible obligar a todos a preocuparse por un conjunto específico de convenciones para saltos de línea y párrafos, o para evitar conversiones de tabulación / espacio.

¿Alguien ofrece alojamiento gratuito de pequeños repositorios de documentos compartidos, con control de versión de texto-documento que puede manejar diferencias de nivel de palabra ( no basadas en líneas)?

Si no, agradecería otras sugerencias basadas en la experiencia (evitemos la especulación, por favor).

Estaba pensando en Git, Subversion, Mercurial, darcs o Bazaar, configurado para manejar las diferencias de nivel de palabra con wdiff, junto con una forma simple de configurar el acceso protegido por claves públicas (por ejemplo, a través de ssh). Sin embargo, ninguno de los proveedores de control de versiones que miré parece ofrecer algo como esto. Para la colaboración científica, las características de "empresa" destacadas por muchas de estas compañías no son muy importantes (muchas sucursales, integración con trac, auditoría por terceros, equipos jerárquicos de proyectos). Pero las diferencias de nivel de palabra parecen críticas pero sin soporte. En mi experiencia, con las diferencias de nivel de línea para los archivos de texto, todos deben evitar formatear párrafos y editores que cambien las pestañas a espacios o viceversa que causen problemas; También parece haber muchos conflictos de edición espurios.

Consulte la pregunta relacionada en MO sobre herramientas para la colaboración , y las preguntas relacionadas en TeX.SE, sobre el control de versiones para documentos LaTeX y los paquetes de LaTeX para el control de versiones . Consulte también el Cuadro de revisión de comparación de alojamiento de SVN para obtener una lista extensa de proveedores de alojamiento, para uno de los principales sistemas de control de versiones.

Editar: La respuesta de Jukka Suomela a la pregunta de TeX.SE "Las mejores herramientas de combinación y diferenciación compatibles con LaTeX para la subversión " parece ser la mejor sugerencia hasta ahora, cubriendo cómo interpretar los deltas a nivel de palabra. Además, Jukka ha explicado cómo las diferencias entre las versiones sucesivas en el repositorio final son independientes de las diferencias a nivel de usuario utilizadas para la detección de conflictos y la fusión de cambios. La respuesta de Jukka en TeX.SE excluye explícitamente las ediciones y fusiones simultáneas, confiando en cambio en el token de edición atómica tradicional para evitar conflictos de edición. Aclarando (y modificando) mi pregunta original, ¿hay alguna manera de garantizar que los conflictos de edición se puedan resolver en función de la diferencia de palabras, en lugar de hacerlo en función de la diferencia de línea? En otras palabras, puedewdiff¿O se deben integrar herramientas similares en la parte de detección de conflictos de las herramientas de control de versiones, similar a la forma en que se pueden ignorar las diferencias de fin de línea y las diferencias en el espacio en blanco?

soft-question research-practice software writing András Salamon
fuente
3
No entiendo bien la pregunta. Por ejemplo, en SVN, las diferencias que se muestran a un usuario son generadas por el cliente, y depende de su cliente SVN (y su configuración) si obtiene diferencias basadas en palabras o diferencias basadas en líneas. La compañía que aloja su repositorio SVN no afecta esto en absoluto.
Jukka Suomela
2
@suresh Si está editando documentos de texto (escritos), a menudo es difícil tener que escanear una línea completa en un diff para ver que alguien ha cambiado una coma. El comportamiento correcto generalmente es mostrar la unidad mínima de cambio. O considere el comportamiento si alguien no usa saltos de línea. Luego, cambiar una sola palabra hará que todo el párrafo se muestre en el diff para que pueda encontrar el pequeño cambio.
Mark Reitblatt
2
No uso saltos de línea dura para ajustar las líneas. En mi código fuente de Latex, una línea de texto física suele ser un párrafo completo de texto. El editor puede ajustarlo para mostrarlo, dependiendo del ancho de la ventana actual. Simplifica mucho las cosas; nunca hay necesidad de preocuparse por cosas como si debería volver a redactar un párrafo o acordar el ancho de línea "correcto" con sus coautores. Sin embargo, necesitará una herramienta de diferencia de nivel de palabra para ver los cambios rápidamente.
Jukka Suomela
2
@Andras Mi punto fue que el sistema de VC solo necesita poder reconstruir las dos revisiones en el lado del cliente, y no sorprende que todos los sistemas de VC puedan hacer eso. Lo que necesita es una utilidad de combinación de tres niveles a nivel de palabra, pero no sé de ninguna. (Por ejemplo, TortoiseMerge y kdiff3 están basados ​​en líneas). Una vez que tenga dicha utilidad, cualquier sistema de VC que le permita especificar una utilidad de fusión externa será suficiente. (Eso incluye svn, bzr, git, hg ...)
Maverick Woo
3
Una fuente de confusión aquí es que hay un algoritmo de diferencia binario incorporado (que opera en el nivel de bytes individuales) que SVN usa en la comunicación entre el servidor y el cliente, y también internamente por el servidor para mantener el repositorio compacto. Esto es simplemente una optimización; no es visible para el usuario y el mismo algoritmo de diferencia binario se puede aplicar a cualquier tipo de archivo. Todas las cosas visibles para el usuario (diferencias legibles por humanos, fusión, resolución de conflictos ...) suceden en el lado del cliente.
Jukka Suomela

Respuestas:

11

He usado git para colaborar en algunos documentos escritos en látex. Tendrás que cumplir con algunas reglas:

  • Comience cada oración en una nueva línea, el látex ignora estas nuevas líneas siempre que no haya una línea en blanco
  • Utilice la misma configuración para formatear (tabulación / espacios / ancho máximo de texto)
  • Para obtener mejores resultados, cree un archivo .gitattributes en su repositorio y agregue la línea *.tex diff=tex. Esto hace que diff sea consciente de la sintaxis de tex y conduce a una salida más significativa.

Luego puede usar git diff --color-wordsy gitk --color-wordsver las diferencias de palabras (también vea este artículo Diferencias palabra por palabra en Git sobre cómo configurar git para usar siempre el algoritmo word-diff para mostrar el registro git diff / git).

Para reducir las fusiones manuales, puedo recomendar el uso de archivos separados para secciones y subsecciones (dependiendo del tamaño de su documento).

Davy Landman
fuente
Consideraré hacer esto para mis propios documentos, parece ser una manera fácil de lograr la mayoría de mis objetivos. Pero no todos quieren trabajar de esta manera ...
András Salamon
2
Para las personas que dudan en trabajar de esta manera, puede usar TortoiseGit si no les gusta la línea de comando git. Si se trata de cada oración en una nueva parte de línea, siempre que no haya un ancho de texto máximo forzado, esto no es tan importante. (He trabajado en algunos proyectos sin esa regla)
Davy Landman
En general, estoy de acuerdo en que git es una buena opción. Pero, ¿por qué los archivos separados para (sub) secciones reducen el número de fusiones manuales? También me pregunto cómo comenzar cada oración en una nueva línea ayuda (a veces las oraciones se mezclan en el proceso de edición).
dd1
con respecto a la separación de archivos: en ese momento, no entendía los detalles exactos de la fusión de git, por lo que en realidad no es necesario, pero aún así es aconsejable por otras razones. La oración en una nueva línea es muy importante, ya que la mayoría de las herramientas alrededor de git siempre muestran cambios de línea, si luego usa otra estrategia, por ejemplo, deje que el editor haga saltos de línea, cada vez que alguien cambie 1 palabra en un párrafo, tendrá que buscar sucedió, y en caso de fusión automática: de ninguna manera.
Davy Landman
4

Realmente quiero hacerme eco de los demás y sugerirle que se siente y elabore una buena estrategia SVN. Utilizo SVN para alojar toda mi estructura de "investigación":

  • Gestión de referencia JabRef
  • PDF descargados
  • Artículos

Es genial porque contiene todo y, por supuesto, proporciona una historia. La advertencia es que necesitas tu propio servidor. Pero si tiene alguna máquina Windows existente (o lo que le resulte más cómodo) puede instalarla simplemente a través del servidor VisualSVN . Luego crea cuentas apropiadas para los colaboradores, y les da acceso a un área apropiada (es decir, tal vez acceso de lectura a su archivo bibtex JabRef, y lectura / escritura en un área de artículo compartida "en progreso").

TortiseSVN se puede utilizar como cliente de Windows para interactuar con SVN. Debe tener cuidado al mover / eliminar archivos y copiar carpetas (SVN almacenará metadatos dentro de carpetas ocultas en cada una de sus carpetas, por lo que debe ejecutar el comando eliminar desde dentro de SVN para deshacerse de él, toma un poco de tiempo acostumbrarse a, pero vale la pena la inversión).

Luego, cuando trabajan con un colaborador, claramente también deben usar SVN. Pero, de nuevo, la inversión en aprendizaje no es inútil. Y a través de algún pensamiento, también puede tenerlo para tener acceso de solo lectura a su archivo jabref (quizás a través de la función 'externa' en svn).

De esta manera, con un poco de reflexión y un poco de esfuerzo, puede estar en una situación en la que está editando documentos de la forma habitual, confirmando cambios todas las noches, actualizando por la mañana y resolviendo todos los conflictos fácilmente.

Realmente lo recomiendo Cuantas más personas configuren sus propios SVN, mejor, ya que solo mejorará las opciones de colaboración en el futuro (aunque, por supuesto, sería beneficioso si tal vez hubiera una forma `` estándar '' de establecer un repositorio científico).

- Editar: De hecho, he escrito una propuesta de este tipo aquí: Estrategia para la colaboración científica con LaTeX y SVN . Propone hacer uso de la función externa svn para permitir una colaboración fácil entre personas con una configuración similar. Avíseme si necesita cambiar o si simplemente no es apropiado.

Seda del mediodía
fuente
4

Mientras leía su gran publicación y buscaba una solución, me topé con la opción de colorear los cambios a nivel de palabra en gitk . El parámetro gitk parece ser una característica nueva y / o no documentada ya que la finalización automática no lo ofrece y la página de manual de gitk no lo enumera.
Aquí están las opciones que encontré:

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

Puedes encontrar varias discusiones sobre ese tema buscando "diff --color-words" gitk .

Editar:
Esto es lo que parece ...

Diferencias coloreadas a nivel de palabra usando gitk

JJD
fuente
1

Entiendo muy bien el problema. He comenzado a usar Kaleidoscope para diferencias con git. Es solo para Mac, pero sus comparaciones funcionan mejor que wdiff, y también tiene una interfaz y actualizaciones en vivo.


fuente
2
Para mí, parece que Kaleidoscope es solo una herramienta de diferencia basada en líneas que, además, resalta los cambios dentro de cada línea. No es un reemplazo para wdiff y amigos. Kaleidoscope produce diferencias ilegibles si, por ejemplo, solo toma un párrafo de texto y cambia algunos saltos de línea. Las herramientas basadas en Wdiff simplemente ignoran los cambios en los saltos de línea.
Jukka Suomela