Comment gérer de grands actifs d'art de manière appropriée dans DVCS?

Question

Est-il une bonne façon de gérer de gros actifs (c'est à dire plus de 1000 images, des animations flash, etc.) avec un DVCS outil tel que hg et git. Comme je le vois, pour cloner les référentiels qui sont remplis avec 4 GO actifs semble être une surcharge inutile que vous serez de vérifier les fichiers. Il semble plutôt encombrant si vous avez le code source mélangés avec les fichiers de ressources.

Quelqu'un aurait-il des idées ou de l'expérience en faisant cela, dans un contexte de développement web?

Answer 1

Ce sont les quelques réflexions que j'ai eu sur cette question de l'objet. En fin de compte, vous pourriez avoir besoin pour garder actifs et de code distincts que possible. Je peux penser à plusieurs stratégies possibles:

Distribué, Deux Référentiels

Actifs dans un repo et le code dans l'autre.

Avantages

• Dans le contexte de développement web, vous n'aurez pas besoin de cloner le géant de l'actif référentiel si vous n'êtes pas travailler directement avec les fichiers graphiques. Cela est possible si vous disposez d'un serveur web qui gère les actifs séparé de contenu dynamique (php, asp.net, RoR, etc.) et est en cours de synchronisation avec l'actif des pensions.

Inconvénients

• DVCS outils ne sont pas à suivre d'autres référentiels que leur propre donc il n'y a pas de dommages directs BOM (Bill of materials) de support, c'est à dire il n'y a aucune façon de savoir quand les deux référentiels sont synchronisés. (Je suppose que c'est ce que git-sous-module ou repo est pour).

  Exemple: l'artiste ajoute une nouvelle image dans un référentiel et programmeur ajoute la fonction de l'utilisation de l'image, cependant, quand quelqu'un a de backtrack versions, ils sont contraints à une certaine façon de garder une trace de ces changements sur leur propre.

• Actif référentiel de frais généraux, même si elle n'affecte que ceux qui ne l'utilisent.

Distribué Des, Un Référentiel

Les actifs et code résident dans un même référentiel, mais ils sont dans deux séparer les répertoires.

Avantages

• Gestion des versions de code et les actifs sont imbriqués de manière MOB est pratique. Retour en arrière est possible sans trop de difficulté.

Inconvénients

• Depuis le contrôle de version distribué des outils de garder une trace de l'ensemble de la structure de projet, il n'y a généralement aucun moyen de le vérifier un répertoire.
• Vous avez toujours le problème avec le référentiel de frais généraux. Plus encore, vous avez besoin de vérifier les éléments d'actif ainsi que le code.

Les deux stratégies énumérées ci-dessus présentent l'inconvénient d'avoir un grand frais généraux, car vous avez besoin de cloner le gros atout de référentiel. Une solution à ce problème est une variante de la première stratégie ci-dessus, deux référentiels; garder le code dans le VCS distribués pensions de titres et les actifs centralisé des VCS repo (comme SVN, Alienbrain, etc).

Considérant la façon dont la plupart des graphistes de travailler avec des fichiers binaires il n'y a généralement pas besoin de branche, sauf si c'est vraiment nécessaire (nouvelles fonctionnalités nécessitant beaucoup d'actifs qui n'est pas nécessaire que beaucoup plus tard). L'inconvénient est que vous aurez besoin de trouver un moyen de sauvegarder le référentiel central. D'où une troisième stratégie:

Hors Référentiel de l'Actif (ou de l'Actif de la CMS à la place)

Code dans le référentiel comme d'habitude et les actifs ne sont pas dans le référentiel. Les actifs doivent être mis dans une sorte de contenu/media/système de gestion d'actifs au lieu ou au moins sur un dossier qui est régulièrement sauvegardé. Cela suppose qu'il y a très peu besoin de revenir en arrière versions avec des graphiques. Si il ya un besoin pour le suivi ensuite changements graphiques sont négligeables.

Avantages

• Ne pas gonfler le dépôt de code (très utile pour, par exemple, git comme c'est souvent le cas de contrôle de fichiers)
• Permet une utilisation souple de l'actif, comme le déploiement des actifs de serveurs dédiés pour seulement actifs
• Si sur CMS, avec une API, les actifs devraient être relativement faciles à traiter dans le code

Inconvénients

• Sans BOM soutien
• Pas facile de vastes version le suivi de soutien, cela dépend de la stratégie de sauvegarde de vos actifs

Answer 2

Des pensées, sans expérience: j'aurais en effet séparée de code à partir des données. En supposant qu'il existe un ensemble d'images qui appartient à la demande, je voudrais juste garder sur un serveur centralisé. Dans le code, que je ne puis organiser (par le biais de codage explicite) que l'application peut intégrer à la fois locale ou à distance de l'actif. Les personnes contribuant pouvez ensuite mettre de nouvelles images dans leur magasin local, au premier abord, en l'intégrant à une sorte de (explicite) procédure de transfert dans le magasin central lorsque requis et approuvé.

Answer 3

J'ai lutté avec moi-même. Comme vous l'avez dit, la gestion des versions Sgb de l'actif peut être d'une grande douleur.

Pour les projets qui nécessitent une participation externe j'ai trouvé Mercurial pour être un travail de la solution, mais ne pas une grande. Il mange des disques à l'espace pour les fichiers de grande taille et peut être assez lent, selon les circonstances.

Pour ma maison-dans le travail de conception, je préfère utiliser de simples outils de synchronisation (rsync, synctoy, que ce soit d'autre) pour garder les répertoires à jour entre les serveurs/machines et ensuite faire le contrôle de version manuellement. Je trouve que j'ai rarement besoin de contrôle de version pour rien au-delà d'une révision majeure.