Quel est le degré de capacité de Subversion à stocker beaucoup de fichiers binaires?
Je cherche un endroit pour mettre quelques Go de documents (principalement .doc et .xls). Mon équipe a déjà un serveur Subversion configuré pour gérer les documents que nous créons, je préférerais donc l'utiliser si possible. Dans quelle mesure Subversion gérera-t-il toutes ces tâches supplémentaires? Il s’agit pour la plupart d’informations héritées et n’auront jamais qu’une version, mais il est possible que quelques documents soient mis à jour.
On m'a prévenu que SVN n'était pas particulièrement convivial pour les gros fichiers binaires. Je me méfie d'essayer pour voir si cela fonctionne car ils seront toujours dans l'historique du référentiel même si je les supprime plus tard.
Des alternatives? Nous aurons besoin de la possibilité de commenter et/ou de marquer les documents, mais nous pouvons utiliser un service de type Delicious combiné aux URL des documents en SVN (ou similaire).
Plus tard Je ne suis pas si inquiet pour les diffs sur les binaires car, comme indiqué ci-dessus, ils ne changeront pas beaucoup. Je suis d'accord avec un léger problème s'ils le font - ce n'est pas pire que SharePoint.
Il y a une différence entre beaucoup de gros fichiers binaires et un grand nombre de fichiers binaires.
D'après mon expérience, SVN convient pour des fichiers binaires individuels de plusieurs centaines de mégaoctets. Les seuls problèmes que j'ai vus commencent à se produire avec des fichiers individuels d'environ un gigaoctet environ. Les opérations échouent pour des raisons mystérieuses et inconnues, éventuellement le SVN ne peut pas gérer les problèmes liés au réseau.
Je ne suis au courant d'aucun problème SVN lié au nombre de fichiers binaires, à leur manque de capacité de fusion et au fait que les fichiers binaires ne peuvent souvent pas être efficacement stockés sous forme de deltas (SVN peut utiliser des deltas).
Alors;
- 1000 fichiers de 1 Mo = bien.
- 100 fichiers 10Mo = bien
- 10 fichiers de 100 Mo = bien
- 1> 1000MB fichier = pas une bonne idée.
J'espère que la taille de vos documents rentre dans l'une des catégories fines :)
Dans ma société précédente, nous avons configuré Subversion pour stocker les fichiers CAD. Des fichiers jusqu’à 100 Mo ont été stockés dans Subversion. Si de nombreuses personnes "ajoutent" de gros fichiers au serveur Web Subversion, cela peut être un goulot d'étranglement. Cependant, les mises à jour incrémentielles étaient parfaitement correctes.
Subversion stocké 'delta binaire'. En fait, côté serveur, les fichiers binaires et texte sont traités exactement de la même manière dans le stockage du 'delta'. Consultez la section "Améliorations de l’encodage delta binaire" à la page http://Subversion.tigris.org/svn_1.4_releasenotes.html . Elle indique explicitement "Subversion utilise l’algorithme xdelta pour calculer les différences entre chaînes de octets "(et non des chaînes de" caractères ").
Juste pour l’expérience, j’ai stocké la version 10 de CAD (fichier pièce CATIA). Chaque version, j'ai apporté des modifications mineures à la pièce, puis vérifiez la taille du référentiel côté serveur. La taille totale était d'environ 1,2x pour environ 10 révisions (x - étant la taille du fichier d'origine).
N'oubliez pas de définir la propriété svn: needs-lock. D'après mon expérience, le meilleur moyen consiste à utiliser "auto props" pour définir svn: needs-lock en fonction de l'extension de fichier.
Nous avons construit notre Subversion client exactement pour cela, car nous avons réalisé de gros travaux de conception/conseil qui nécessitaient un contrôle de version. Nous n'avons jamais eu de problèmes avec cela.
Cela dépend de la fréquence à laquelle les fichiers sont mis à jour. Cela ne peut rien faire avec la fusion de fichiers binaires et vous aurez donc mal à chaque fois qu'il y a un conflit. Sinon, il ne s'agit que de stockage et de récupération, et bien que ce ne soit pas aussi efficace que le texte, il le gère toujours parfaitement.
Personnellement, j'utilise Mercurial pour de telles tâches. Je l'ai utilisé pour stocker plusieurs centaines de concerts de médias. Oui, cela prend de l'espace disque, mais l'espace disque est bon marché. Avec Mercurial, vous bénéficiez également de sa distribution. Par conséquent, si vous effectuez une "commande", ou un clone comme on le sait dans Mercurial, vous obtenez le rapport complet, pas seulement un instantané. Si votre serveur meurt, votre entreprise est toujours en activité.