usar - tortoise svn merge branch to trunk

¿Cómo mejor versión de diseño de documentos? (7)

Cuando es posible, guardo todos los archivos "en bruto" en formato de texto (es decir, XML / DocBook, texto plano, LaTeX) además de los PDF renderizados bajo el control de la versión de la versión. Además, trato de usar el número de revisión del repositorio de Subversion como el número de versión del documento.

Si no puede usar el número de revisión automática (es decir, en un documento de Word), le recomiendo usar la fecha de la última modificación. Asegúrese de utilizar la fecha de la última edición y no la macro de la fecha actual, porque la macro de la fecha actual incluirá la fecha en que esté cuando imprima el documento, que probablemente no sea lo que desea. Otra forma de hacerlo es, por supuesto, usar un número de versión incremental tradicional, pero según mi experiencia, a la gente a menudo le cuesta saber qué versión es la última cuando solo se ve un número. La gente suele ser más consciente de las fechas antiguas.

Tener la fecha y / o el número de revisión como parte del encabezado / pie de página de cada página también es una gran ventaja, de esa manera evitará que las personas mezclen las diferentes versiones que se encuentran en sus escritorios ...

Se ha debatido un poco sobre SO ( aquí y aquí ) antes sobre cómo se pueden versionar los documentos de oficina, sin embargo, creo que mi pregunta todavía es un poco diferente.

Mis proyectos de programación comienzan con una carpeta de proyecto que está vacía a excepción de una subcarpeta llamada "Documentos de diseño", que contiene un borrador de la especificación funcional del proyecto para comenzar y luego se expande para contener especificaciones de API o cualquier otra cosa que se necesite.

Naturalmente, compruebo estos archivos en SVN también. Lo que estoy buscando es buenos formatos de archivos y estrategias para jugar bien con todo el proceso de control de versiones, dispersión y fusión. Por ejemplo, creo que sería mejor almacenar archivos de procesador de textos como XML, o los diffs serían feos e inútiles para los lectores humanos? Esto es lo que me gustaría hacer:

Difunde y combine documentos de texto (debe tener OOo, agradable de tener MS Word)
diff (y tal vez fusionar, aunque esto podría ser conceptualmente difícil) dibujos de esquema, como diagramas UML. Estaba pensando que estos podrían ser archivos XML / SVG independientes y estar vinculados a los documentos de texto, pero no sé lo suficiente sobre cómo funcionan estos documentos para decir si eso es realmente posible.
mostrar números de revisión actualizados automáticamente dentro de los documentos de texto (tal vez con svn: palabras clave )

¿Alguien ha hecho este tipo de cosas ya? Probablemente hay una cantidad de documentación y tutoriales sobre archivos OOo, etc. que podría consultar, pero si bien también aprecio los indicadores de estos, principalmente busco informes de primera mano de cosas que funcionaron o no en la práctica.

Editar: Solo para estar seguros, no hay "usuarios no técnicos" involucrados aquí. Solo son programadores y los documentos solo se pueden usar en proyectos de programación. Puede que se publiquen archivos PDF, pero ese será solo otro artefacto de construcción, nada que tenga que ser versionado.

Aún así, realmente no queremos usar Tex o similares. Sé que es genial y todo, pero simplemente no puedo molestarme por un simple documento de texto. Tendríamos que aprenderlo, obtener todos los paquetes extra correctos, agregar representación de Tex-to-PDF a nuestro proceso de compilación, etc. Sería como un pequeño proyecto de programación solo para dos o tres documentos. En todo caso, prefiero usar HTML, pero un procesador de textos todavía me parece una buena opción, excepto que quiero un buen control de versiones.

Hay otro pensamiento: ¿hay algo así como un complemento SVN para OOo o al revés? O incluso, ¿qué se necesitaría para agregar soporte SVN a OOo? Como una opción "Sincronizar" en el menú Archivo y un campo de texto "Número de revisión". Quiero decir, eso no sería realmente parte de nuestro negocio, pero sería genial, y después de todo, soy el jefe.

El problema con OOo es que el formato de archivo es realmente un grupo comprimido de archivos zip (intente cambiar la extensión del archivo a .zip o .7z). Esto hace que sea difícil hacer diffs en.

He estado mirando LaTex y DocBook, pero establecer una plantilla de estilo para usar es bastante difícil. Esta es la parte más difícil de todos los tutoriales.

Así que, básicamente, he renunciado a obtener diferencias significativas de la documentación. Se comprueba como blobs binarios.

Como señaló Aaorn Digulla, una wiki es una gran idea. Debe darse cuenta de que la única forma en que realmente logrará lo que desea es reconsiderar toda su estrategia documental.

Ningún software solucionará el problema de los formatos de archivo incompatibles y no podrá comparar diferentes versiones. Las herramientas que está utilizando ahora son las herramientas incorrectas para el trabajo. Va a ser difícil, incómodo y posiblemente costoso cambiar su conjunto de herramientas y su forma de pensar, pero ese es el costo de poder lograr lo que desea, que terminará pagándose 10 veces.

Solo piense en las dificultades que tuvo inicialmente con los documentos de esquema, diagramas UML e incluso algo tan simple como planear un documento de Word. Aquellos trabajaron hasta este punto y te llevaron hasta aquí, pero el único camino real es pasar a las herramientas que fueron diseñadas para lo que necesitas ahora .

Nota: la solución definitiva podría no ser una wiki, pero definitivamente tampoco es lo que estás usando ahora. Debes explorar un poco y probar algunas cosas.

Hemos utilizado una wiki para la documentación de algunos de nuestros proyectos. Tiene un excelente seguimiento de versiones por entrada, pero no a nivel de documento, por lo que exportamos los documentos y también los registramos para las líneas de base.

Una wiki parece una buena idea aquí, pero si no es una buena opción, puede considerar usar Sphinx (o similar) con ReStructured Text .

Aunque esto también sería un "pequeño proyecto de programación", le proporcionaría HTML como salida mientras mantiene las diferencias bastante claras y legibles. Configurarlo sería, creo, menos esfuerzo que para LaTeX; la curva de aprendizaje sería bastante más pequeña; y si necesita LaTeX y PDF en el futuro, está esperando por usted.

El cliente de TortoiseSVN (Windows) para SVN sabe lo suficiente sobre Open Office que cuando le pide que los diferencie, una vez que tiene las versiones necesarias, abre Office con ambos documentos abiertos, mostrando las diferencias. Yo uso esto mucho. Me imagino que hay soluciones aún más sofisticadas, y cosas similares para Mac / Linux / OS / 360 o lo que sea, pero para este usuario muy técnico que a menudo se siente muy poco técnico porque quiere su almuerzo, TortoiseSVN ( http: //tortoisesvn.tigris .org / ) entrega.

Los editores WYSIWYG (Word, OpenOffice) generalmente no ven una razón por la cual alguien más deba meterse con sus archivos, por lo que es imposible encontrar un editor que un usuario no técnico pueda usar y que sea amigable con un sistema de control de versiones. Excepción: git tiene un filtro que puede examinar los archivos de OpenOffice . Sin embargo, no estoy seguro de si puedes usar la expansión de palabras clave.

Sugiero usar una wiki y una semana de capacitación para que los usuarios puedan usarla. Resuelve todos tus problemas (algunos wikis incluso pueden ser registrados en un sistema de control de versiones). Como dije en una publicación diferente , el único obstáculo es que los usuarios tardarán unos días en acostumbrarse a la idea. Después de eso, les encantará.