Git+un gran conjunto de datos?
version-control dataset (4)
Como alternativa, los datos podrían residir en una carpeta sin seguimiento (por git) que está sincronizada por un servicio p2p. Usamos esta solución para un conjunto de datos de varias decenas de GB y funciona bastante bien.
- El conjunto de datos se comparte directamente entre los pares.
- Dependiendo del software p2p, las versiones anteriores pueden conservarse y restaurarse.
- El conjunto de datos se actualizará automáticamente en caso de cambios.
syncthing es el software que utilizamos.
A menudo estamos trabajando en un proyecto donde se nos ha entregado un gran conjunto de datos (por ejemplo, un puñado de archivos de 1 GB cada uno), y estamos escribiendo un código para analizarlo.
Todo el código de análisis está en Git, para que todos puedan verificar los cambios dentro y fuera de nuestro repositorio central. ¿Pero qué hacer con los conjuntos de datos con los que trabaja el código?
Quiero los datos en el repositorio:
- Cuando los usuarios primero clonan el repositorio, los datos deben venir con.
- Los datos no son 100% de solo lectura; de vez en cuando se corrige un punto de datos, o se produce un cambio menor de formato. Si se producen cambios menores en los datos, se debe notificar a los usuarios en la próxima compra.
Sin embargo, no quiero los datos en el repositorio git:
- git clonar una copia de repuesto (por lo que tengo dos versiones en mi directorio de inicio) extraerá algunos GB de datos que ya tengo. Prefiero tenerlo en una ubicación fija [establecer una regla según la cual los datos deben estar en ~ / datos] o agregar enlaces según sea necesario.
- Con los datos en el repositorio, la copia a un dispositivo de memoria puede ser imposible, lo cual es molesto cuando estoy trabajando en cien líneas de código.
- Si se corrige un punto de datos erróneo, nunca volveré a ver la versión errónea. Los cambios en el conjunto de datos pueden ser rastreados en un archivo de texto simple o por la persona que proporcionó los datos (o simplemente no lo hizo).
Parece que necesito una configuración con un repositorio principal para el código y un repositorio auxiliar para los datos. ¿Alguna sugerencia o truco para implementar esto con gracia, ya sea dentro de git o en POSIX en general? Todo lo que he pensado es, de una manera u otra, un tumulto.
Esto suena como la ocasión perfecta para probar git-annex :
git-annex permite administrar archivos con git, sin verificar el contenido del archivo en git. Si bien esto puede parecer paradójico, es útil cuando se trata de archivos más grandes de lo que git puede manejar actualmente, ya sea debido a limitaciones en la memoria, el tiempo de suma de comprobación o el espacio en disco.
use submódulos para aislar sus archivos gigantes de su código fuente. Más sobre eso aquí:
http://git-scm.com/book/en/v2/Git-Tools-Submodules
Los ejemplos hablan de bibliotecas, pero esto funciona para cosas grandes e infladas como muestras de datos para pruebas, imágenes, películas, etc.
Debería poder volar mientras se desarrolla, solo deteniéndose aquí y allá si necesita ver nuevas versiones de datos gigantes.
A veces ni siquiera vale la pena rastrear cambios en tales cosas.
Para resolver sus problemas al obtener más clones de datos: si su implementación de git admite enlaces duros en su sistema operativo, esto debería ser una brisa.
La naturaleza de su conjunto de datos gigante también está en juego. Si cambia algo de eso, ¿está cambiando las manchas gigantes o unas pocas filas en un conjunto de millones? Esto debería determinar cuán efectivo será el VCS en jugar un mecanismo de notificación para él.
Espero que esto ayude.
Git BUP afirma hacer un buen trabajo al realizar copias de seguridad incrementales de archivos grandes.
Creo que BUP asume un repositorio separado para hacer su trabajo, por lo que terminaría usando submódulos de todos modos. Sin embargo, si quieres una buena reducción de ancho de banda esta es la cosa