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

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?

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).

Sugiero echar un vistazo a:

LaTeX / Escritura colaborativa de documentos LaTeX ,

y el documento relacionado:

Herramientas para la escritura colaborativa de documentos científicos de LaTeX .

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.

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 ...

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.