Esiste un VCS distribuito in grado di gestire file di grandi dimensioni?

Question

Esiste un sistema di controllo della versione distribuito (git, bazaar, mercurial, darcs ecc.) in grado di gestire file più grandi della RAM disponibile?

Devo essere in grado di eseguire il commit di file binari di grandi dimensioni (ad es.set di dati, video/immagini di origine, archivi), ma non ho bisogno di essere in grado di differenziarli, basta solo essere in grado di eseguire il commit e quindi aggiornare quando il file cambia.

L'ho guardato l'ultima volta circa un anno fa, e nessuno dei candidati ovvi lo ha permesso, dal momento che sono tutti progettati per differire in memoria per la velocità.Ciò mi ha lasciato con un VCS per la gestione del codice e qualcos'altro (software di gestione delle risorse o semplicemente rsync e script) per file di grandi dimensioni, il che è piuttosto brutto quando le strutture di directory dei due si sovrappongono.

Answer 1

Sono passati 3 anni da quando ho posto questa domanda, ma, a partire dalla versione 2.0 Mercurial include il file estensione largefiles, che realizza ciò che inizialmente stavo cercando:

L'estensione largefiles consente di tenere traccia di file binari di grandi dimensioni e incomprimibili in Mercurial senza richiedere una larghezza di banda eccessiva per cloni e pull.I file aggiunti come file di grandi dimensioni non vengono tracciati direttamente da Mercurial;piuttosto, le loro revisioni sono identificate da un checksum e Mercurial tiene traccia di questi checksum.In questo modo, quando cloni un repository o inserisci changeset, i file di grandi dimensioni nelle revisioni precedenti del repository non sono necessari e vengono scaricati solo quelli necessari per l'aggiornamento alla versione corrente.Ciò consente di risparmiare sia spazio su disco che larghezza di banda.

Answer 2

Nessun sistema di controllo della versione distribuito gratuito supporta questo.Se desideri questa funzionalità, dovrai implementarla.

Puoi cancellare git:sono interessati alle prestazioni grezze per il caso d'uso dello sviluppo del kernel Linux.È improbabile che accetterebbero mai il compromesso in termini di prestazioni nel ridimensionamento di enormi file binari.Non conosco Mercurial, ma sembra che abbiano fatto scelte simili a quelle di Git nell'accoppiare il loro modello operativo al loro modello di archiviazione per le prestazioni.

In linea di principio, Bazaar dovrebbe essere in grado di supportare il tuo caso d'uso con un plugin che implementa formati albero/ramo/repository la cui strategia di archiviazione e implementazione su disco è ottimizzata per il tuo caso d'uso.Nel caso in cui l'architettura interna ti blocchi e rilasci codice utile, mi aspetto che gli sviluppatori principali ti aiutino a correggere l'architettura interna.Inoltre, potresti stipulare un contratto di sviluppo di funzionalità con Canonical.

Probabilmente l’approccio più pragmatico, indipendentemente dallo specifico DVCS, sarebbe quello di costruire un sistema ibrido:implementa un archivio di file di grandi dimensioni e memorizza i riferimenti ai BLOB in questo archivio nel DVCS di tua scelta.

Informativa completa:Sono un ex dipendente di Canonical e ho lavorato a stretto contatto con gli sviluppatori di Bazaar.

Answer 3

SÌ, SCM in plastica.E' distribuito e gestisce file enormi in blocchi da 4Mb quindi non ha il limite di doverli caricare interamente su memoria in qualsiasi momento.Trovi un tutorial sul DVCS qui:http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

Answer 4

BUP potrebbe essere quello che stai cercando.È stato creato come estensione della funzionalità git per eseguire i backup, ma in effetti è la stessa cosa.Suddivide i file in blocchi e utilizza un hash mobile per rendere il contenuto del file indirizzabile/archiviare in modo efficiente.

• https://github.com/bup/bup
• http://blogs.kde.org/node/4440

Answer 5

Penso che sarebbe inefficiente archiviare file binari in qualsiasi forma di sistema di controllo della versione.

L'idea migliore sarebbe quella di archiviare file di testo di metadati nel repository che fanno riferimento agli oggetti binari.

Answer 6

È necessario distribuirlo?Presumibilmente l'unico grande vantaggio che subversion ha per i VCS distribuiti più recenti è la sua capacità superiore di gestire file binari.

Answer 7

Sono giunto alla conclusione che la soluzione migliore in questo caso sarebbe utilizzare ZFS.

Sì, ZFS non è un DVCS ma:

• È possibile allocare spazio per il repository creando un nuovo FS
• Puoi tenere traccia delle modifiche creando istantanee
• È possibile inviare snapshot (commit) a un altro set di dati ZFS