Existe-t-il un VCS distribué capable de gérer des fichiers volumineux?

Question

Existe-t-il un système de contrôle de version distribué (git, bazar, mercurial, darcs, etc.) pouvant gérer des fichiers plus volumineux que la RAM disponible?

Je dois pouvoir valider des fichiers binaires volumineux (ensembles de données, vidéo / images source, archives), mais je n'ai pas besoin de pouvoir les différencier, il suffit de pouvoir les valider, puis de les mettre à jour lorsque le fichier est modifié. .

La dernière fois que j’ai examiné cette question il ya environ un an, aucun des candidats les plus évidents ne l’a permis, car ils sont tous conçus pour différer en mémoire pour plus de rapidité. Cela me laissait un VCS pour gérer le code et quelque chose d’autre (logiciel "Asset Management" ou simplement rsync et scripts) pour les gros fichiers, ce qui est plutôt moche lorsque les structures de répertoires des deux se chevauchent.

Answer 1

Cela fait 3 ans que je pose cette question, mais depuis la version 2.0, Mercurial inclut le L'extension largefiles permet de réaliser ce que je recherchais à l'origine:

  

L’extension largefiles permet de suivre des fichiers binaires volumineux et incompressibles dans Mercurial sans nécessiter une bande passante excessive pour les clones et les extractions. Les fichiers ajoutés en tant que fichiers volumineux ne sont pas suivis directement par Mercurial; au lieu de cela, leurs révisions sont identifiées par une somme de contrôle, et Mercurial suit ces sommes de contrôle. Ainsi, lorsque vous clonez un référentiel ou importez des ensembles de modifications, les fichiers volumineux des révisions plus anciennes du référentiel ne sont pas nécessaires et seuls ceux nécessaires à la mise à jour vers la version actuelle sont téléchargés. Cela permet d'économiser de l'espace disque et de la bande passante.

Answer 2

Aucun système de contrôle de version distribué gratuit ne prend cela en charge. Si vous souhaitez cette fonctionnalité, vous devrez la mettre en œuvre.

Vous pouvez supprimer git: ils s'intéressent aux performances brutes pour le cas d'utilisation du développement du noyau Linux. Il est improbable qu'ils acceptent jamais le compromis performance entre la mise à l'échelle de gros fichiers binaires. Je ne connais pas Mercurial, mais ils semblent avoir fait des choix similaires à ceux de git en associant leur modèle d’exploitation à leur modèle de stockage en termes de performances.

En principe, Bazaar devrait pouvoir prendre en charge votre cas d'utilisation avec un plug-in implémentant les formats arbre / branche / référentiel dont la stratégie de stockage sur disque et d'implémentation est optimisée pour votre cas d'utilisation. Si l’architecture interne vous bloque et que vous publiez du code utile, je suppose que les développeurs principaux vous aideront à réparer l’architecture interne. Vous pouvez également définir un contrat de développement de fonctionnalités avec Canonical.

L’approche la plus pragmatique, quel que soit le DVCS spécifique, serait probablement de construire un système hybride: implémenter un magasin de fichiers volumineux et stocker les références aux blobs de ce magasin dans le DVCS de votre choix.

Divulgation complète: Je suis un ancien employé de Canonical et j'ai travaillé en étroite collaboration avec les développeurs de Bazaar.

Answer 3

Oui, SCM en plastique . Il est distribué et gère d’énormes fichiers par blocs de 4 Mo. Il n’est donc pas limité de les charger entièrement à tout moment. Trouvez un tutoriel sur DVCS ici: http://codicesoftware.blogspot.com/2010/03/ Distribué-développement-pour-windows.html

Answer 4

BUP est peut-être ce que vous cherchez. Il a été construit comme une extension de la fonctionnalité git pour effectuer des sauvegardes, mais c'est effectivement la même chose. Il divise les fichiers en morceaux et utilise un hachage défilant pour rendre le contenu du fichier adressable / faire un stockage efficace.

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

Answer 5

Je pense qu'il serait inefficace de stocker des fichiers binaires sous toute forme de système de contrôle de version.

La meilleure idée serait de stocker dans le référentiel des fichiers texte de métadonnées qui référencent les objets binaires.

Answer 6

Doit-il être distribué? Soi-disant, le principal avantage de la subversion pour les nouveaux VCS distribués est sa capacité supérieure à gérer les fichiers binaires.

Answer 7

Je suis arrivé à la conclusion que la meilleure solution dans ce cas serait d’utiliser le ZFS.

Oui, ZFS n'est pas un DVCS mais:

• Vous pouvez allouer de l'espace au référentiel en créant un nouveau système de stockage
• Vous pouvez suivre les modifications en créant des instantanés
• Vous pouvez envoyer des instantanés (commits) à un autre ensemble de données ZFS