J'ai trouvé l'outil Timeline de Pixel Novel, mais je me demandais si je pouvais utiliser une application de subversions pour gérer mes fichiers de conception. Je ne suis pas encore sûr de tout comprendre sur Subversions, et je n'ai pas trouvé beaucoup d'informations sur son utilisation dans le domaine du design.
Réponses:
Vous ne savez pas comment cela fonctionne avec la compression de données, mais vous voudrez peut-être essayer git annex : http://git-annex.branchable.com
Si vos fichiers ne sont pas si gros, git ou mercurial peuvent être le meilleur choix. Évitez SVN à tout prix
Il y a quelques bonnes suggestions sur /programming/29292/version-control-for-graphics
Voici quelques citations de la question sur http://StackOverflow.com
"Github a récemment introduit" les modes d'affichage d'image ", jetez un œil: https://github.com/blog/817-behold-image-view-modes "
-
"J'ai réussi à utiliser perforce sur de très gros projets (+100 Go), mais nous avons dû envelopper l'accès au serveur de contrôle de version avec quelque chose d'un peu plus convivial pour les artistes."
-
"TortoiseSVN peut montrer des révisions d'images côte à côte, ce qui est vraiment utile. Je l'ai utilisé avec différentes équipes avec un grand succès. Les artistes ont adoré avoir la possibilité de faire reculer les choses (après s'être habitués aux concepts Cela prend cependant beaucoup de place. "
Timeline fonctionne avec "n'importe quel svn" et est apparemment aussi un plugin d'indesign.
SVN est probablement principalement hors sujet ici, mais en un mot, il suit un seul fichier d'origine et stocke ensuite les modifications apportées à ce fichier d'origine au fil du temps ou vous forcez un nouveau «point de base».
La seule façon de revenir de manière fiable à une ancienne version est de les comparer manuellement et de décider. Les repos étaient à l'origine destinés principalement aux fichiers de texte brut (code source), et il est assez facile de regarder les modifications brutes et de décider lesquelles vous voulez parce qu'elles étaient lisibles par l'homme au départ, mais pour les données binaires (images, formats propriétaires, formats de conteneur etc.), les modifications ne sont pas sous une forme lisible par l'homme. La chronologie semble être un moyen de gérer cela en prenant les différents commits et en les affichant.
Le lien de Scott vers l'image GIT est destiné à des formats spécifiques et ( je suppose ) ne prend probablement pas en charge les fichiers PSD et en particulier les fichiers d'indesign (c'est-à-dire les formats binaires aléatoires). La chronologie semble être un plugin qui repose simplement sur l'application hôte pour présenter les données binaires (une bonne solution, au moins sur papier IMO).
Le fonctionnement de base d'un dépôt svn est que vous disposez d'un processus serveur qui gère le suivi et le stockage principal de toutes les différences. Ensuite, vous avez un processus client sur votre machine de travail qui s'exécute toujours et est connecté aux menus contextuels, etc. (ou utilise la ligne de commande). Vous créez un dossier vide local, puis vous le marquez en tant que dossier SVN en "extrayant" une version d'un référentiel sur le serveur. À partir de là, vous pouvez les modifier à votre guise, mais vous devez utiliser le client svn pour déplacer la copie ou la supprimerle ou les fichiers sur le système de fichiers. Si vous ajoutez de nouveaux fichiers au dossier SVN local, vous devez ensuite les étiqueter pour qu'ils soient suivis. Tout cela se produit localement et le dépôt n'est mis à jour avec des révisions que lorsque vous "validez" manuellement le dépôt. Votre copie locale est une version unique et vous devez communiquer de nouveau avec le serveur SVN pour rétablir un fichier.
Tout cela est lent par rapport à aucun SVN, même pour les fichiers texte, surtout si vous extrayez un gros projet. Les projets sur lesquels j'ai utilisé SVN (passé) étaient principalement basés sur du code source, avec 20 à 30 000 petits fichiers et un paiement complet nécessitait une pause-café. Je soupçonne que cela était plus dû à la surcharge de débit de tant de petits fichiers et moins de fichiers binaires plus gros de la même taille de stockage aurait été plus rapide.
GIT fonctionne légèrement différemment, je pense.
J'utilise git pour mes projets Illustrator et InDesign. Je dois admettre qu'il n'est pas facile de gérer les conceptions de cette façon. Voici quelques conseils que je souhaite pour vous aider:
Soyez prudent avec SVN, j'apprendrais git. C'est mieux avec des tailles de fichiers énormes, mais permet toujours de contrôler / gérer la subversion. Juste plus léger.
La plupart des systèmes de version sont conçus pour gérer des formats de fichiers non binaires. En d'autres termes, des fichiers texte.
Ils sont légers, faciles à bifurquer et à ramifier, à fusionner et à suivre les modifications incrémentielles.
Des systèmes comme SVN et GIT ne sont pas conçus pour gérer des fichiers PSD. Ce sont des fichiers gigantesques et difficilement comparables d'une version à l'autre et impossibles à «fusionner» et à bifurquer, etc.
Certains peuvent autoriser les fichiers binaires - je crois que SVN le permet, mais d'après mon expérience, il n'essaie pas de les versionner. Au lieu de cela, il remplace simplement la dernière version. Donc d'une utilité limitée là-bas.
De plus, si vous maîtrisez le modèle de contrôle de version de travail, vous apprendrez à vous enregistrer fréquemment. C'est génial pour le code, mais gonflera bientôt votre référentiel à des tailles ingérables si vous archivez des versions de fichiers PSD de 100 Mo toutes les 20 minutes.
En raison d'un manque de branchement et autres, cela signifie que vous ferez probablement encore beaucoup de cela manuellement, en ayant plusieurs copies de fichiers légèrement modifiés. Cela signifie, hélas, des fichiers encore plus volumineux qui doivent être stockés, ce qui empêche encore l'utilisation du contrôle de version.
En tant que tel, pour les fichiers binaires lourds, vous voudrez garder l'extérieur d'un système de contrôle de version tel que celui-ci et examiner les outils DAM (Digital Asset Management).
Hélas, il n'y a pas beaucoup de systèmes de contrôle de version conçus spécifiquement pour les documents lourds. Sharepoint en est un, mais il est maladroit, à peine automatisé et rarement configuré pour gérer des fichiers de la taille des PSD.
L'alternative la plus probable est le propre Version Cue d'Adobe qui, je crois, a été transformé en produit «Adobe Drive»: