¿Hay un VCS distribuido que pueda administrar archivos grandes?

13

¿Hay un sistema de control de versiones distribuidas (git, bazaar, mercurial, darcs, etc.) que pueda manejar archivos más grandes que la memoria RAM disponible?¿Hay un VCS distribuido que pueda administrar archivos grandes?

Necesito poder asignar grandes archivos binarios (es decir, conjuntos de datos, video/imágenes fuente, archivos), pero no necesito poder distinguirlos, solo puedo confirmar y actualizar cuando el archivo cambios.

La última vez que miré esto hace aproximadamente un año, y ninguno de los candidatos obvio lo permitió, ya que están diseñados para diferir en memoria para velocidad. Eso me dejó con un VCS para administrar código y algo más (software de "gestión de activos" o simplemente rsync y scripts) para archivos grandes, lo cual es bastante feo cuando las estructuras de directorios de los dos se superponen.

Fuente

2008-09-16 joelhardi

12

Han pasado 3 años desde que hice esta pregunta, pero, a partir de la versión 2.0 Mercurial incluye la largefiles extension, que logra lo que estaba buscando originalmente para:

El La extensión largefiles permite rastrear archivos binarios grandes e incompresibles en Mercurial sin requerir un ancho de banda excesivo para clones y pulls. Los archivos agregados como archivos grandes no son rastreados directamente por Mercurial; más bien, sus revisiones se identifican por una suma de comprobación, y Mercurial realiza un seguimiento de estas sumas de comprobación. De esta forma, cuando se clona un repositorio o se extraen conjuntos de cambios, no se necesitan los archivos grandes en las revisiones anteriores del repositorio, y solo se descargan los que se necesitan para actualizar a la versión actual.Esto ahorra espacio de disco y ancho de banda.

Fuente

2011-11-03 08:00:57 joelhardi

2

Creo que sería ineficaz almacenar archivos binarios en cualquier forma de sistema de control de versiones.

La mejor idea sería almacenar archivos de texto de metadatos en el repositorio que hace referencia a los objetos binarios.

Fuente

2008-09-16 08:45:36 pobk

+0

Gracias por su respuesta. Pero sí, quise decir lo que pregunté. Necesito la versión de archivos de gran tamaño: hay otra clase de software "administración de activos empresariales" que básicamente es VCS/Aperture/Version Cue en un servidor para activos de medios. – joelhardi

+1

Creo que el punto que estaba tratando de tratar (no me da miedo tomar café) fue que la mayoría de los sistemas VCS no están diseñados para la versión de objetos binarios. Como dices, hacen diffs en memoria y almacenan el delta ... No tiene mucho sentido el versionar binarios, ya que son intrínsecos. – pobk

0

¿Tiene que ser distribuido? Supuestamente, la gran subversión de beneficios que tiene una VCS distribuida más nueva es su capacidad superior para manejar archivos binarios.

Fuente

2008-09-16 08:50:52

+0

Gracias por la respuesta, pero sí, lo hace. Estoy de acuerdo en que SVN maneja bien los archivos binarios, lo cual es parte de lo que me desconcierta: los VCSes que probé previamente actuaron como si el fallo de segmentación en un archivo de 400 MB fuera un comportamiento aceptable. – joelhardi

10

Ningún sistema de control de versiones distribuidas libre es compatible con esto. Si desea esta característica, deberá implementarla.

Puede escribir git: están interesados en el rendimiento bruto para el caso de uso de desarrollo de kernel de Linux. Es improbable que alguna vez acepten el compromiso de rendimiento en escalar a enormes archivos binarios. No sé sobre Mercurial, pero parecen haber tomado decisiones similares a las de Git al combinar su modelo operativo con su modelo de almacenamiento para el rendimiento.

En principio, Bazaar debe ser compatible con su caso de uso con un complemento que implemente formatos de árbol/sucursal/repositorio cuya estrategia de almacenamiento e implementación en disco está optimizada para su caso de uso. En caso de que la arquitectura interna lo bloquee y libere un código útil, espero que los desarrolladores principales lo ayuden a arreglar la arquitectura interna. Además, puede configurar un contrato de desarrollo de funciones con Canonical.

Probablemente el enfoque más pragmático, independientemente del DVCS específico sería construir un sistema híbrido: implementar una gran tienda de archivos y almacenar referencias a blobs en esta tienda en el DVCS de su elección.

Descripción completa: Soy un ex empleado de Canonical y colaboré estrechamente con los desarrolladores de Bazaar.

Fuente

2008-09-16 11:44:11 ddaa

+0

Muchas gracias por la respuesta. Me correspondí con algunos desarrolladores de Hg y BZR el año pasado y lo que dijeron refleja tu evaluación: la gente de BZR dijo "Hmm, eso es interesante, podrías codificarlo" y lo consideramos, pero el costo de tiempo no tenía sentido en comparación con solo usando SVN o hackeando ... – joelhardi

+0

... una solución híbrida en la que estamos cometiendo hashes de archivos o algo así. Todos los proyectos de DVCS parecen estar fuertemente impulsados por el caso de uso de desarrollo distribuido de FOSS, a diferencia de SVN y productos comerciales, que tienen una gama más amplia de usos en mente. Hg y BZR son grandes proyectos, muy malos para mí. – joelhardi

4

Sí, Plastic SCM. Se distribuye y administra archivos enormes en bloques de 4Mb, por lo que no está limitado al tener que cargarlos completamente en mem en cualquier momento. Encontrar un tutorial sobre DVCS aquí: http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

Fuente

2010-03-30 12:48:47 pablo

+0

Gracias por la sugerencia, ya no estoy trabajando en este problema, pero su respuesta será útil para las personas que leen este hilo. Desde su sitio web, parece haber compatibilidad con Linux/BSD/OS X para Plastic SCM, ya que es C#/Mono. Sin embargo, están usando SQL para el almacenamiento de backend, así que todavía soy escéptico sobre el soporte/desempeño de "archivos grandes" ... por lo que originalmente quise decir cosas hasta, por ejemplo, fuentes de video DV en el rango 1-10 G. Chunking/diffing algo así de SQLite * puede * funcionar, pero ¿qué tan bien? Si alguien tiene alguna experiencia con esto, sería una gran información para agregar. – joelhardi

+0

Hola, en realidad solo ejecutamos otra prueba con archivos de 2Gb ... se trata de almacenar 4mb blobs en una base de datos, que es ... extremadamente rápido ... usando SQL Server, o Firebird o incluso MySQL ... Plastic tiene una opción para guardar archivos en fs también. – pablo

3

BUP podría ser lo que estás buscando. Fue construido como una extensión de la funcionalidad de git para hacer copias de seguridad, pero eso es efectivamente lo mismo. Divide los archivos en fragmentos y utiliza un hash continuo para hacer que el contenido del archivo sea accesible/haga un almacenamiento eficiente.

Fuente

2012-06-18 15:41:37 Catskul

0

llegué a la conclusión de que la mejor solución en este caso sería el uso de la ZFS.

Sí ZFS no es un DVCS pero:

Puede asignar espacio para repositorio a través de la creación de la nueva FS
Puede realizar un seguimiento de los cambios mediante la creación de instantáneas
Puede enviar instantáneas (cometa) a otro Dataset de ZFS

Fuente

2017-07-08 02:15:13

¿Hay un VCS distribuido que pueda administrar archivos grandes?

Respuesta

Cuestiones relacionadas