Le 15/05/2013 19:38, Emmanuel Thierry a écrit : > > De ce point de vue git fait ce qu'on lui demande. Si tu demandes à tes devs > de n'utiliser qu'un seul upstream tu as une architecture centralisée avec git. > Par contre empêcher des développeurs d'avoir des branches locales par pure > doctrine c'est juste les empêcher de travailler. Derrière ils vont contourner > le problème pour pouvoir garder un environnement local qui leur correspond, > ou encore régler les problèmes causés par subversion lui-même (qui est un > outil de versioning antédiluvien), et ils vont perdre du temps à faire tout > ça au lieu de faire des choses utiles. > > Je ne comprends pas en quoi du closed source impose la centralisation. Que tu > fasses du closed-source ou de l'open-source tu seras obligé en tant que > développeur: > * de tester tes modifs avant de les pousser sur le dépôt central > * de maintenir des modifications non-terminées en local parce que tu dois > pipeliner entre plusieurs tâches (oh ! une demande de bugfix > ultra-prioritaire qui arrive !) > * de te préserver un environnement custom en local pour le déboggage de ta > partie du code > Tout ce que tu ne peux pas faire (facilement) avec svn. > Je comprend ce point de vue en tant que développeur, mais le côté sysadm fait qu'au contraire tu n'as pas à tester sur ton poste en local mais tu dois utiliser un environnement de dev / recette / preprod conforme à la prod. Après que tu passes par de la virtualisation ou du vhost par développeur pour être suffisament isolé et pas être impacté par les modifs en cours des voisins, c'est à voir mais c'est pas au dev de faire des environnements de test. J'ai suffisamment donné depuis 10 ans à entendre c'est pas ma faute ça marche sur mon poste, c'est la prod qui est pas bien réglé. Sauf que les contraintes de sécurités entre la prod et son poste perso sont pas les même.
Bref la centralisation vient de là principalement. Svn n'est pas si obsolète que cela, au quotidien il n'y a pas de différence à mon sens et niveau. Par contre le cas de devoir faire plusieurs branches et devoir les resynchroniser j'ai pas vu un seul client qui se dit pourtant Agile ne pas perdre un temps fou là dessus. Alors que structurer les demandes release par release et que tout le monde se concentre sur les points définis c'est tellement plus stable dans le temps. Enfin c'est mon ressenti dans l'encadrement, l'hébergement et l'infogérance de clients type Agile. J'en ait deux qui font des releases plusieurs fois par jour, chaque release contient les tâches nécessaires à l'obtention d'un élément urgent ou évolution. Tous les dev bossent ensemble en même temps sur les tâches à faire (découper en des éléments super simples). Et avec eux j'ai aucun souci, stabilité de l'application à toute épreuve, aucun rollback fait. A voir donc, autant Git pour kernel je comprend même si j'aimerais voir comment les mainteneurs arrivent à récupérer et merger autant de branches différentes tout en maintenant une stabilité et la gestion des dépendances. Mais là c'est un autre niveau de dev et puis l'outils a été codé pour eux et ils ont pas de commerciaux ou marketeux pour les perturber dans leur travaux, ça compte énormément aussi.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
