Le 16 mai 2013 à 00:56, Wallace <wall...@morkitu.org> a écrit : > 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.
Alors si je suis un développeur ça te dérangera pas que je déploie un gdb sur le kernel de l'environnement de test pour faire du pas à pas sur la pile IPv6 ? :P (bon, j'admets en plus que tu as déjà répondu à ce point plus bas ! ;)) Bon, ceci dit, même pour du code plus courant, par exemple du code PHP, tu veux pouvoir lancer des outils de debug pour dumper/modifier facilement les variables sans avoir à ajouter un var_dump(), commiter, attendre que le serveur récupère le code, et voir le résultat. En tant que développeur, je considère qu'il faut de la souplesse pour pouvoir travailler, quitte à perdre un peu de temps à se resynchroniser avec tout le monde avant de faire une release. > > 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. Disons que une fois que tu as touché à git, tu ne peux plus t'en passer… :) > > 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. J'admets que cela dépend de beaucoup de paramètres: * Le type de développements (custom pour un client, ou bien produit sur étagère) * La durée des échéances (quelques heures à plusieurs mois) * La méthodologie de gestion de projet (agile ou "classique") * L'architecture du projet (monolithique ou modulaire) > > 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. Disons que à ce que je comprends git est *très* utile pour des projets qui durent dans le temps, où il faudra gérer de front la situation courante (bugfixes à apporter dans différentes versions), et les développements à venir (améliorations). Egalement sur des projets modulaires où un module est délégué à une personne ou un groupe de personnes, avec quelqu'un qui sera considéré comme responsable de cette brique et rapportera toutes les modifications sur cette brique à l'entité centrale, etc. Ceci dit, comme je le disais, tu peux décider de l'utiliser de manière totalement centralisée et synchrone (en passant la consigne aux développeurs), il gardera son intérêt (taille du dépôt, capacités d'historique et de recherche, possibilités de rebase, …) Cordialement Emmanuel Thierry _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
