Le Tue, 13 May 2014 22:57:32 +0200 Julien Dombre <m...@indepnet.net> a écrit:
>Le 13/05/2014 22:31, David DURIEUX a écrit : >> >> >> (question subsidiaire : un projet de migration vers git est-il prévu, >> un jour ?) >> >> La question qui fache... mais je crois qu'on est de plus en plus à le >> demander ;) >> >La question qui fache pourquoi ? >Il n'y a pas de question qui fache, il y a des points de vue >différents et des argumentaires qui aujourd'hui n'ont pas réussi à >faire basculer les choses. >Quand à l'argumentaire "on est de plus en plus à le demander", j'ai >sûrement des trous de mémoire, mais j'estime le beaucoup à environ 3 >demandes exprimées en 5 ans... On en avais discuté plusieurs fois >Après, combien de gens sont prêts à se reformer (s'ils ne le sont pas >déjà) à un autre système et à changer leur mode de fonctionnement ? C'est la même chose avec ceux qui utilisent GIT au quotidien, c'est extrèmement compliqué d'utiliser SVN >Git est certainement plus complet mais également plus complexe et avec >une logique complètement différente. On est d'accord >Ce qui est certain, c'est que ce n'est pas avec ce genre d'argument >que la discussion avancera. Les gros plus sont la gestion des branches. Ce qui est formidable c'est qu'on crée une nouvelle branche facilement et pas besoins de recréer un GLPI complet juste pour cette branche, elle se met en place sur ton dépot / glpi actuel (oui ça remplace les fichiers du répertoire). Exemple avec SVN et un plugin : T'as un plugin et tu crée une branche pour essayer de développer une feature, tu dois recopier un GLPI avec ta branche à coté Exemple avec GIT et un plugin : Tu crée ta branche et t'as rien besoin de faire, tu reste avec tes fichiers et tu peux rebasculer sur ta branche principale rapidement avec seulement une commande. Il y a d'autres points intéressants avec GIT, c'est la possibilité de faire une branche par feature. Tu peux avoir une personne qui travaille sur sa branche avec des modifications dans tout le code, et les autres peuvent faire d'autres features sur la branche principale ou différente. En synchronisant la branche principale sur la branche de travail, ça permet d'avoir les modifs des autres, résoudre les conflits au fur et à mesure si besoin et merger la branche dans la branche principale sans problème une fois la travail fais. Pour les plugins, j'ai de plus en plus de contributions sur les plugins depuis 6 mois et GIT est très utilisé par les contributeurs (plugin fusioninventory, monitoring, supportcontract, surveyticket...). Du coup j'ai plusieurs plugins dont le code n'est pas sur la forge, mais ils sur un dépot git. En soit celà n'est pas très grave sauf qu'il devient difficile d'utiliser la gestion des issues de redmine dans ces cas là et donc gérer une bonne roadmap. Voilà de mon point de vue. Je sais qu'on peut avoir plusieurs types de dépôts sur redmine (un unique pour chaque projet) et donc peut être mettre GIT ou SVN pour les projets suivant le choix du leader du plugin. Les 2 soucis principaux c'est de maintenir 2 types de scripts pour les nightsdaily et les fichiers pour le catalogue de plugins. David ++ ps: désolé pour le mail précédent rapide et sans argumentaire, ce n'était pas très intelligent de ma part :/ >C'est le même principe que pour les features de GLPI, sans analyse >claire et précise, il est compliqué d'estimer l'intérêt, les gains et >la rentabilité de l'investissement de mise en place. > >Cordialement, > >Julien Dombre > > > > >_______________________________________________ >Glpi-dev mailing list >Glpi-dev@gna.org >https://mail.gna.org/listinfo/glpi-dev _______________________________________________ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
