versiones tortoise subversion create control svn ms-office openxml configuration-management

tortoise - svn vs git



¿Subversion almacenará de manera eficiente documentos de Office OpenXML? (4)

He estado administrando Subversion como un repositorio de almacenamiento de documentos de ingeniería para mi empresa. Está funcionando bastante bien, sin embargo tengo una pregunta sobre cómo los formatos de MS Office 2007 son (deben ser) manejados por Subversion.

Estoy buscando en una hoja de cálculo de Excel 2007 (extensión .xlsx) en mi copia de trabajo que Subversion ha aplicado la aplicación de propiedad svn: mime-type / octet-stream . Esto significa que Subversion se trata como binario, ¿verdad?

Esperaba que los nuevos formatos de documentos de MS Office fueran almacenados eficientemente por Subversion. Tengo entendido que se realizará una copia completa de un archivo binario en cada confirmación de ese archivo, mientras que si el archivo es de texto , un pequeño cambio en el archivo dará como resultado que se agregue una pequeña cantidad de datos adicionales al repositorio (en una situación típica al menos).

No entiendo gran parte de los detalles de XML, pero pensé que un archivo XML era texto y que, por lo tanto, sería subversivo.

¿Es posible configurar Subversion para que los documentos de MS Office OpenXML se almacenen de manera eficiente?

Seguimiento (2009-11-09) : He encontrado que los documentos de Office se pueden almacenar como texto sin formato con los formatos de documento XML de Office 2003 (Excel: Hoja de cálculo XML 2003 ; Documento Word: Word XML . Hay una advertencia acerca de la pérdida de formateo , pero todavía tengo que encontrar una pérdida notable de formato.

¿Alguna vez has tratado de abrir un archivo OpenXML en un editor de texto?

Para hacerlo breve: no es texto, sigue siendo binario. Entonces, no, no puedes hacer que Subversion lo maneje diferente.

Del artículo de OpenXML en wikipedia :

Un archivo Office Open XML es un paquete OPC compatible con ZIP que contiene documentos XML y otros recursos.

En otras palabras, los archivos OpenXML son en realidad archivos zip con archivos XML en ellos. La compresión o el cifrado "codifica" los datos, saboteando la capacidad de la subversión de generar deltas entre revisiones. Esto no está relacionado con el svn:mimetype . Subversion considera que todos los archivos son binarios al generar deltas.

En holandés tenemos un dicho "medir es saber". El siguiente gráfico muestra los resultados de un experimento en el que importé un documento de 500K OpenXML en un repositorio de SVN 1.6 (revisión 1). Luego agregué un párrafo de otro documento, guardado y comprometido. Esto se repitió 5 veces (revisión 2 a 6).

Como puede ver, comprometer una nueva revisión de docx que solo agrega un párrafo le costará aproximadamente 150K de espacio en disco. Esto es mucho más eficiente que simplemente almacenar una copia de cada revisión sin la ayuda de un sistema de control de versiones.

También repetí el experimento con un repositorio de pruebas separado descomprimiendo cada revisión del docx. Como puede ver, el almacenamiento de las revisiones de documentos sería mucho más eficiente si no estuviera comprimido. También es interesante ver que la propia compresión de datos de subversión es tan eficiente como zip . Almacenar la primera revisión de un docx descomprimido en subversión ocupa aproximadamente el mismo espacio que el docx original.

YMMV.

Subversion maneja bastante bien los archivos binarios. No almacena una copia completa para cada confirmación, sino solo una diferencia binaria eficiente.

Vea las FAQ sobre esto.