Wrapper a SVN commit y checkout para comprimir

Posible duplicado:
comprimir binarys en SVN?

duplicado exacto por el mismo autor : comprimir binarys en SVN?


Hola,

Quiero build una secuencia de commands para envolver los problemas de confirmación y pago. Quiero comprimir files binarys antes de enviar y descomprimir justo después de finalizar la compra.

¿Cuál es la manera de hacerlo? ¿El command IMPORT es preferible a COMMIT porque no hay comparativa delta? Sé que no sería eficiente en el uso del espacio, ¿pero aún así?

gracias, Oded.

La interacción entre los algorithms delta binarys de Subversion, la compression en los files rastreados y el propio uso interno de compression del server puede ser complejo.

Aquí hay un ejemplo

Tomé una copy del x86 emacs binary (alnetworkingedor de 10MB, 4MB comprimido con gzip) como mi "file binary". Escribí un pequeño progtwig que "edita" un file binary sobrescribiendo 4 bytes consecutivos en una position aleatoria con datos aleatorios.

Luego escribí tres scripts para simular 100 commits en las siguientes tres modas:

el file está comprimido con gzip en el repository

Para cada repetición: descomprimimos el file, luego realizamos nuestra edición, luego lo comprimimos y luego lo registramos.

Tamaño final del repository: 9.6 MB

(Esto fue mejor de lo esperado hasta que me di count de que debido a la forma en que funciona gzip, los bytes antes de la edición aleatoria (la mitad del file, en promedio) serán idénticos a los de la versión anterior, incluso después de la compression).

el file no está comprimido en el repository

Para cada repetición: simplemente realizamos nuestra edición y luego verificamos los cambios.

Tamaño final del repository: 5.1 MB

el file se importa desde cero cada vez

Para cada repetición: copymos el binary (no usando svn copy) en un nuevo file, editamos esta copy, lo agregamos y confirmamos los cambios. Esto es equivalente a una import ya que no hay una connection histórica con la copy anterior del file.

Tamaño final del repository: 403 MB

Solo para hacerte una idea de la compression del lado del server de Subversion, repetí esta testing, solo que esta vez comprimí los files binarys en el lado del cliente antes de agregarlos y confirmarlos cada vez.

Tamaño final del repository: 392 MB

Entonces, sea lo que sea que esté haciendo la subversión, parece tan buena como gzip.


Sus preguntas lo hacen parecer que está asumiendo que la compression del lado del cliente lo ayudará. Es muy posible que no lo haga.

En mi experiencia, solo vale la pena hacerlo cuando:

  1. El file es grande
  2. La compression que está utilizando es mucho más estricta que la que logra Subversion. (por ejemplo, si está usando bzip2 o lzma)
  3. El file rara vez se edita.

Comprimir files boostá el espacio ocupado por su repository SVN.

¿Por qué? El server SVN intenta almacenar solo los deltas resultantes de la diferencia binaria. Por lo tanto, normalmente solo se deben almacenar las partes del file que se cambiaron.

Sin embargo, si comprime los files, el más mínimo cambio cambiará por completo el resultado de la compression. El server SVN deberá almacenar el file comprimido completo para cada confirmación, en lugar de solo la parte modificada.