Sauvegarde de style Git des fichiers binaires

Question

Je suis en train d'intégrer le système de contrôle de version GIT dans 3ds max pour contrôler la version des fichiers .max.

J'ai testé git avec des fichiers max pendant plusieurs semaines et j'ai constaté qu'il correspond à mes besoins, mais, de toute façon, git est un peu trop compliqué pour ce genre de tâches. Ce que je recherche, c'est un programme qui fonctionne exactement comme (enfin, presque) git, mais :

1. est un programme Windows natif - git a échoué plusieurs fois sur mes dossiers partagés en réseau et a détruit mes fichiers binaires max. C'est le principal problème, et je ne sais pas comment le résoudre.
2. ne traite pas (et n'essaie même pas de) le contenu des fichiers. Je pense que cela accélère le flux de travail.
3. a une interface proche de TortoiseGIT.

Ce que ce logiciel doit avoir est :

1. commandes de commit et de journal
2. prise en charge des branches
3. être distribué et ne pas être orienté serveur comme Perforce.

J'ai testé Mercurial, mais c'est vraiment lent sur de gros fichiers binaires. Si quelqu'un sait comment l'accélérer (en désactivant la gestion du contenu, je suppose) et a TortoiseHg entièrement fonctionnel, toute information serait grandement appréciée.

Merci!

Answer 1

Les fichiers binaires entretiennent une relation plutôt ambivalente avec le VCS parce que :

• ils ne se fusionnent pas (donc tout le "support des branches" n'est pas si intéressant)
• ils ne se différencient pas très bien (ce qui signifie que le stockage de leur historique n'est pas très compact)
• ils peuvent généralement être générés
• ou ils peuvent être récupérés à partir d'autres types de référentiels

Les fichiers binaires font partie des limites de Git car ils tendent à ralentir tout le flux de travail, et ne pas d'échelle en taille (le référentiel devient rapidement trop grand pour être géré/sauvegardé efficacement).

La question est donc : pourriez-vous stocker ces fichiers dans un autre référentiel que VCS ?
Peut-être un référentiel Maven (géré par un gestionnaire de référentiels comme Nexus, pas exactement distribué, mais conçu pour référencer des versions précises de tout type d'ensemble de fichiers).

---

Jakub Narębski (actuel contributeur Git) souligne à juste titre un projet de fork de Git capable de gérer plus efficacement de gros fichiers.

[git-bigfiles (ok, le logo du projet est génial ;) )

La question demeure : est-ce qu'un VCS est l'outil approprié pour gérer de tels objets volumineux ?
Car dans mon expérience, la question du "nettoyage de l'historique" sera posée un jour ou l'autre, en raison d'une utilisation croissante de l'espace disque.
Et les VCS ne sont fondamentalement pas conçus pour "nettoyer" leur historique.
Git lui-même ne peut le faire sans changer sa clé SHA1, rendant toute future publication dans d'autres référentiels publics problématique.

Answer 2

Ce que je ne comprends pas, c'est pourquoi vous voulez utiliser un DVCS sans pouvoir différencier et donc en profiter, comme le dit le premier commentaire.

Je conseillerais deux directions possibles:

• jeter un œil à archiva et/ou ivy (outils Java) qui ont été conçus pour gérer la distribution de fichiers binaires, tels que les fichiers jar, aux développeurs, mais cela pourrait être trop axé sur Java (ou même sur le développement) pour votre cas d'utilisation, ou

• essayer d'utiliser rync et ses possibilités de sauvegarde (rsync peut enregistrer autant de versions que vous souhaitez au lieu de remplacer la copie précédente par la nouvelle). Cela semble bien adapté à vos besoins : fonctionne bien sur Windows, gère très bien les binaires, ainsi que les fichiers texte, est très efficace en termes de bande passante (peut compresser), et gère la sauvegarde avec plusieurs versions. La seule chose qui vous manquerait serait une interface graphique, idéalement intégrée à l'explorateur Windows. Peut-être qu'il en existe, je ne sais pas..

J'espère que cela vous aidera.

À votre santé,
Christophe.

\= Les sauvegardes sont pour les faibles. Les vrais hommes téléchargent leurs données sur un site FTP et demandent à tout le monde de le mettre en miroir. --Linus Torvalds =

Answer 3

Vous voudrez peut-être examiner Veracity qui a été conçu en tenant compte de cette exigence. L'installateur Windows inclut un client similaire à Tortoise. (Je ne sais pas si l'installateur Mac dispose d'une interface similaire. Je sais que l'installateur Linux n'a actuellement pas une telle interface.)

Liens pertinents :

• Télécharger
• Premiers pas (client Windows)
• Premiers pas (ligne de commande)
• Tableau comparatif des DVCS (à noter, le tableau créé par l'équipe Veracity)... les plus grandes différences par rapport à git sont que vous ne pouvez pas rebaser - c'est une limitation par conception, aucune modification de l'historique n'est autorisée - et vous ne pouvez pas faire de balayage - je ne sais pas si c'est une limitation par conception ou non

Answer 4

Avez-vous envisagé d'utiliser Autodesk Vault? Il fonctionne bien avec 3dsmax (nous l'utilisons depuis de nombreuses années, à la fois pour Inventor et 3dsmax). http://www.autodesk.com/products/autodesk-vault-family/features

Answer 5

Concernant git détruisant vos fichiers binaires max,
avez-vous défini core.autocrlf=false?

GIT serait un contrôle de source assez inutile s'il détruisait les sources.
Cette question sur notre propre SO va plus loin dans la gestion des différences concernant CR & LF dans GIT.