Archive:Subversion
Sommaire
Une anecdote
Paul anime le moine.
Pierre anime l'elfe.
Jacques anime le nain.
Dans la scène a13, le nain parle, le moine écoute, l'elfe regarde.
Nicolas construit la scène avec des imports de décor: il enregistre son fichier sur le serveur a13_001.blend.
Paul, Pierre, Jacques récupère le fichier a13_001.blend sur leur clé USB, il sont courageux, font du bon boulot, ils reviennent la semaine suivante avec leurs fichiers modifiés contenant chacun l'animation de leur personnage.
Scénario 1: chacun a gardé le même nom de fichier et le copie sur le serveur, et c'est Jacques qui gagne parce qu'il copie en dernier: au mieux les autres gardent leur version sur leur clé, Nicolas les récupère, importe les actions de Paul et Pierre dans le fichier de Jacques.
Scénario 2: (scénario 1) x 115 scènes = 345 fichiers
Scénario 3: Jacques n'a pas pu venir la semaine suivante, ...
Scénarion 4: Avec SVN, la fusion des fichiers ne sera pas automatique parce que les fichiers *.blend sont des binaires et non des fichiers textes, mais cela devrait être gérable.
Résumé de la doc svnbook
Une très bonne doc en français : choisir le HTML multi-pages svnbook.red-bean.com
C'est un roman de 300 pages, quelques extraits pour comprendre son intérêt.
Intro
La mission essentielle d'un logiciel de gestion de versions est de permettre l'édition collaborative et le partage de données. Mais il existe différentes stratégies pour arriver à cette fin.
Tous les logiciels de gestion de versions doivent résoudre le même problème fondamental : comment le logiciel va-t-il permettre aux utilisateurs de partager l'information, tout en les empêchant de se marcher mutuellement sur les pieds par accident ? Il est vraiment trop facile pour les utilisateurs d'écraser malencontreusement les changements effectués par d'autres dans le dépôt.
Le travail de Harry est perdu ou, du moins, perdu dans la version finale du fichier, et ceci probablement par accident.
Verrouillage
Prenons un exemple de la vie réelle où ce type de problème apparaît. Harry et Sally sont deux graphistes travaillant sur le même projet (du marketing pour le patron d'un garage). Au coeur d'une affiche de ce projet se trouve l'image d'une voiture dont la carrosserie a besoin d'être réparée, stockée dans un fichier image au format PNG. L'agencement de l'affiche est pratiquement terminé, et Harry et Sally sont contents de la photo qu'ils ont choisie pour leur voiture endommagée : une Ford Mustang bleue de 1967, avec un gnon sur l'aile avant gauche.
C'est alors, comme c'est souvent le cas dans le domaine du graphisme, que des contraintes extérieures imposent de changer la couleur de la voiture. Sally met donc à jour sa copie de travail à la révision HEAD, lance son outil d'édition de photos et commence à modifier la photo de manière à obtenir une voiture rouge cerise. Pendant ce temps, Harry, particulièrement inspiré ce jour-là, décide que l'image serait plus percutante si la voiture était davantage endommagée. Lui aussi met à jour sa copie de travail à la révision HEAD, puis dessine des fissures sur le pare-brise. Il termine son travail avant que Sally ne termine le sien, admire son chef-d'oeuvre et propage les changements. Peu après, Sally en termine avec la nouvelle couleur de la voiture et essaie de propager ses modifications. Mais, comme prévu, Subversion ne parvient pas à valider la propagation et informe Sally que sa version de l'image n'est pas à jour.
Voilà où résident les difficultés : si Harry et Sally avaient effectué leurs changements sur un fichier texte, Sally aurait simplement mis à jour sa copie de travail, recevant au passage les modifications de Harry. Dans le pire des cas, ils auraient modifié la même portion du fichier et Sally aurait eu à résoudre les conflits manuellement. Mais, ici, nous avons affaire à des images binaires, pas des fichiers texte. Et s'il est relativement facile de décrire ce que devrait être l'image finale, il y a très peu de chance qu'un logiciel soit suffisamment intelligent pour détecter les parties communes de l'image sur laquelle les artistes ont travaillé, les changements effectués par Harry et les changements effectués par Sally, et pour en tirer une image d'une Mustang Rouge avec un pare-brise fissuré !
Clairement, les choses se seraient mieux passées si Harry et Sally avaient sérialisé leurs modifications : par exemple, si Harry avait attendu et dessiné ses fissures sur la voiture nouvellement rouge de Sally, ou si Sally avait changé la couleur d'une voiture avec un pare-brise déjà fissuré. Comme indiqué dans la section intitulée « Modèle copier-modifier-fusionner », la plupart de ces problèmes disparaissent complètement quand une communication parfaite existe entre Harry et Sally [15]. Mais comme un système de gestion de versions est en fait un mode de communication, il s'ensuit que si ce type de logiciel facilite la sérialisation de tâches d'édition non parallélisables, c'est plutôt une bonne chose. C'est ici que l'implémentation du concept verrouiller-modifier-libérer dans Subversion prend tout son sens. Il est temps de parler de la fonctionnalité de verrouillage de Subversion, qui est similaire aux mécanismes permettant de « réserver pour modifications » des fichiers dans d'autres systèmes de gestion de versions.
En fin de compte, la fonctionnalité de verrouillage existe afin de minimiser les pertes de temps et les efforts. En autorisant un utilisateur à s'arroger logiciellement le droit exclusif de modifier un fichier dans le dépôt, cet utilisateur peut être suffisamment confiant dans le fait que son travail ne sera pas vain — la propagation de ses changements réussira. Aussi, en signifiant aux autres utilisateurs qu'une sérialisation a lieu pour un objet suivi en versions, ces utilisateurs peut raisonnablement s'attendre à ce que cet objet soit modifié par quelqu'un d'autre. Eux aussi peuvent alors éviter de perdre leur temps et leur énergie sur des modifications qui ne pourront pas être fusionnées en raison d'un problème de mise à jour du fichier correspondant.
Remarque
Si les modifications d'un fichier *.blend ne concernent que des actions, la fusion se fait facilement, manuellement bien-sûr, en important les actions modifiées.
Recherche sur qui a utilisé ou utilise SVN dans un projet d'animation avec Blender
Elephant Dream
- Le projet Orange Elephant Dream 2005 ou les débuts de svn à la Fondation Blender sur une animation, avec le commentaire 19 qui est en fait la suite du premier post.
- La fin de http://www.blender.org/development/architecture/blender-file-format/ de mars 2009
Durian / Sintel
Une video de Colin du projet Durian Sintel de 2010: Library Linking
Il parle de SVN, import avec liens realtifs, et Blender Aid
Des confrères
http://forum.openmuffin.net/showthread.php?tid=9 blender 2.49 ou 2.50 ?
http://forum.openmuffin.net/showthread.php?tid=46 on utilise SVN ou pas ?
Comment l'infographiste utilise SVN
kdesvn
Un client SVN avec une interface User Friendly et compréhensible pour le novice, même moi j'ai compris ! kdesvn est dans les dépots
Voir la page détaillée
RapidSvn
Suite à une première expérience avec kdesvn, RapidSvn s' est avéré plus facile à utiliser que kdesvn !
En pratique
Chacun fait une copie locale du serveur sur sa clè USB, rentre chez lui, travaille sur sa clè, en utilisant un client SVN.
Chaque semaine, au labo, il lance kdesvn, se connecte sur sa clè, fait "Propager". Si les fichiers sont nouveaux, ils seront copié sur le serveur. Les fichiers *.blend modifiés entre temps sur le serveur, seront en erreur : il n' ya pas de logiciel qui puissent faire une fusion automatique de fichiers binaires. Il faut traiter manuellement la fusion en ouvrant les 2 fichiers et en intégrant les modifs de l'un dans l'autre par des imports.
