Pourtant, que ce soit avec giT ou bzr, on voit toujours revenir le principe d'un référentiel central qui, finalement, définit les sources officielles d'un projet.
Il me semble qu'il y a deux notions mélangées : d'une part le fait qu'un projet finit par livrer une unique version à ses utilisateurs (firefox 3.0, ou bzr 1.3, etc.). Ce sont effectivement, in fine, les sources officielles du projet.
D'autre part, et c'est très différent, les modalités pour y parvenir. A ce titre, un système décentralisé peut apporter beaucoup plus de flexibilité : tests de nouvelles fonctionnalités dans une branche à part, plus de souplesse sur les modes connectés/déconnectés, et donc sur l'organisation des équipes de développeurs (extreme programming ou autre). Toutes ces choses sont possibles, mais plus difficiles à mettre en oeuvre, il me semble, via SVN et consort.
Après, clairement, dans une organisation projet informatique "traditionnelle", les développeurs ne sont pas loin géographiquement les uns des autres, le "chef de projet" est pas loin pour décider de comment faire les choses, les développeurs travaillent sur des parties assez différentes ce qui peut faciliter les "merge" sans conflit....
C'est la différence entre interface/implémentation. Le résultat c'est l'interface que tu proposes, l'API, l'implémentation c'est la manière.
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par Xavier Verne (site web personnel) . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 2.
Pourtant, que ce soit avec giT ou bzr, on voit toujours revenir le principe d'un référentiel central qui, finalement, définit les sources officielles d'un projet.
Il me semble qu'il y a deux notions mélangées : d'une part le fait qu'un projet finit par livrer une unique version à ses utilisateurs (firefox 3.0, ou bzr 1.3, etc.). Ce sont effectivement, in fine, les sources officielles du projet.
D'autre part, et c'est très différent, les modalités pour y parvenir. A ce titre, un système décentralisé peut apporter beaucoup plus de flexibilité : tests de nouvelles fonctionnalités dans une branche à part, plus de souplesse sur les modes connectés/déconnectés, et donc sur l'organisation des équipes de développeurs (extreme programming ou autre). Toutes ces choses sont possibles, mais plus difficiles à mettre en oeuvre, il me semble, via SVN et consort.
Après, clairement, dans une organisation projet informatique "traditionnelle", les développeurs ne sont pas loin géographiquement les uns des autres, le "chef de projet" est pas loin pour décider de comment faire les choses, les développeurs travaillent sur des parties assez différentes ce qui peut faciliter les "merge" sans conflit....
C'est la différence entre interface/implémentation. Le résultat c'est l'interface que tu proposes, l'API, l'implémentation c'est la manière.