¿Subversión eficientemente documentos de Office OpenXML?

Question

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 mirando a una hoja de cálculo de Excel 2007 (.xlsx) en mi copia de trabajo de Subversion que se ha aplicado la svn: mime-tipo propiedad application/octet-stream. Esto significa que Subversion se trata como binario, ¿verdad?

Tenía la esperanza de que los nuevos formatos de documentos de MS Office fueran almacenados eficientemente por Subversion. Según entiendo, se realizará una copia completa de un archivo binario en cada confirmación de ese archivo, mientras que si el archivo es texto, un pequeño cambio en el archivo dará como resultado una pequeña cantidad de datos adicionales que se agregarán a el 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 almacenado eficientemente por Subversion.

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

Seguimiento (2009-11-09): Me he dado cuenta que los documentos de Office pueden ser almacenados como texto sin formato utilizando los formatos de documentos XML 2003 Office (Excel: cálculo XML 2003; Palabra: Word Documento XML. Hay una advertencia sobre pérdida de formato, pero todavía tengo que encontrar ninguna pérdida notable de formato.

Answer 1

Desde el OpenXML article on wikipedia:

Un archivo XML Open Office 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 se puede ver, la comisión de una nueva revisión docx que sólo añade un párrafo le costará alrededor de 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 al descomprimir 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 subversion 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.

Answer 2

¿alguna vez ha tratado de abrir un archivo OpenXML en un editor de texto?

para hazlo corto: es no texto, sigue siendo binario. Entonces, no, no puedes hacer que Subversion lo maneje diferente.

Answer 3

Por desgracia, actualmente no puede hacer esto con la subversión, pero no ha habido cierto debate en torno a este:

http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=651443

Answer 4

Subversion maneja ficheros binarios bastante bien. Sí no almacena una copia completa para cada confirmación, pero solo una diferencia binaria eficiente.

Consulte el FAQ acerca de esto.