Je pense simplement que l'usage n'est pas le même.
Dans le cadre de développement purement communautaire les outils distribués sont plus adaptés. Linux en est le meilleur exemple. Lorsque le développement est conduit en entreprise ou dépend d'une organisation (type Eclipse, Apche, ....) (et non pas d'un homme) le centralisé convient mieux. En entreprise d'autant plus qu'il faut la plupart du temps former les prestataires aux outils de l'entreprise.
[caricature]Commence par demander bien bas à l'intgrateur du projet d'accepter de merger tes modifs mêm mineures dans l'archive de référence[/caricature]
[caricature]Et quand mon dd crashe et que j'ai pas fais de push depui 6 mois je perd tout [/caricature]
D'autant que les solutions de sauvegardes ne sont pas faites pour les chiens , elles s'applique au distribué comme au centralisé
C'est plus égalitaire, pas de verrouillage possible par une quelconque cabbale
Si l'intégrateur refuse de prendre en compte tes patche le pb est le même et il n'est pas plus difficie de forker un repository que de déclarer que son archive est la nouvelle référence.
Tout le monde à une copie de l'historique sur son poste (avec des backups en plus, bien sûr)
Mais personne n'a l'archive de toutes les versions du projet lorsqu'il est très volumineux. Dans ce cas tu es bien obligé de prévoir un serveur pour l'héberger au moins par sécurité et tu te retrouves avec les mêmes contraintes que le centralisé
Par ailleurs, bonne chance pour faire un checkout ou un commit dans le train ou l'avion.
Ton checkout/commit se fait dans l'archive local ,ca ne signifie pas que tu mettes à disposition du reste du monde.
Dans les 2 cas tu peux toujours travailler en déconnecté et tu mets à disposition quand tu reviens sur le réseau (commit en centralisé et push/pull en distribué).
Le seul avantage est qu tu peux "sauvegarder" des versions intermédiares de ton travail mais le travail de fusion reste entier.Comme avantage c'est bien maigre comparé aux contraintes d'organisation.
Que se passe t'il quand l'intégrateur est overbooké par un afflux de patch. Le projets doit s'organiser en sous-branche afin d'absorber la charge.
Dans le cas d'un modèles centralisé plusieurs intégrateurs peuvent travailler de concert
Encore une fois l'usage dépend du besoin et je ne pense pas qu'on puisse dire que l'un est meilleur que l'autre.
[^] # Re: bazaar
Posté par golum . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 5.
Dans le cadre de développement purement communautaire les outils distribués sont plus adaptés. Linux en est le meilleur exemple. Lorsque le développement est conduit en entreprise ou dépend d'une organisation (type Eclipse, Apche, ....) (et non pas d'un homme) le centralisé convient mieux. En entreprise d'autant plus qu'il faut la plupart du temps former les prestataires aux outils de l'entreprise.
[caricature]Commence par demander bien bas à l'intgrateur du projet d'accepter de merger tes modifs mêm mineures dans l'archive de référence[/caricature]
[caricature]Et quand mon dd crashe et que j'ai pas fais de push depui 6 mois je perd tout [/caricature]
D'autant que les solutions de sauvegardes ne sont pas faites pour les chiens , elles s'applique au distribué comme au centralisé
Si l'intégrateur refuse de prendre en compte tes patche le pb est le même et il n'est pas plus difficie de forker un repository que de déclarer que son archive est la nouvelle référence.
Mais personne n'a l'archive de toutes les versions du projet lorsqu'il est très volumineux. Dans ce cas tu es bien obligé de prévoir un serveur pour l'héberger au moins par sécurité et tu te retrouves avec les mêmes contraintes que le centralisé
Ton checkout/commit se fait dans l'archive local ,ca ne signifie pas que tu mettes à disposition du reste du monde.
Dans les 2 cas tu peux toujours travailler en déconnecté et tu mets à disposition quand tu reviens sur le réseau (commit en centralisé et push/pull en distribué).
Le seul avantage est qu tu peux "sauvegarder" des versions intermédiares de ton travail mais le travail de fusion reste entier.Comme avantage c'est bien maigre comparé aux contraintes d'organisation.
Que se passe t'il quand l'intégrateur est overbooké par un afflux de patch. Le projets doit s'organiser en sous-branche afin d'absorber la charge.
Dans le cas d'un modèles centralisé plusieurs intégrateurs peuvent travailler de concert
Encore une fois l'usage dépend du besoin et je ne pense pas qu'on puisse dire que l'un est meilleur que l'autre.