La raison est que du code avec des cycles de vie complètement différents est associé à un composant.
Il n'y a que les développeurs SVN pour prétendre le contraire.
Les mêmes qui défendent leur outil en arguant que les branches ne sont pas importantes et qu'on en a pas besoin en agilité, qu'on peut contourner avec le "feature flipping" ou le "branching by abstraction", simplement pour masquer les lacunes de leur outil. Les bonnes pratiques agiles n'empechent pas d'utiliser un bon outil. qui peut le plus peut le moins.
Outre, le fait que ca améliore les performances, le découpage en dépôts permet l'approche par composant: Les composants sont donc ensuite assemblés avec des versions différentes pour former l'application. Ils sont interchangeables.
Ceci renforce aussi la structuration du code, facilite le passage de code entre différentes équipes... Les raisons ne manquent pas.
Bref, c'est une bonne pratique que les équipes sous SVN oublient parfois à leurs dépens...
Concerant ton lien:
Depuis des années nous pratiquons le "trunk based development" dans ma boîte sous Clearcase avant de passer sous Git. D'où l'intérêt de créer un dépôt par composant avec son propre cycle de vie justement.
Les branches par release ne sont intéressantes qu'à partir du moment où plusieurs releases avec des lots de fonctionnalités différentes sont développées en parallèle ou lorsque un SI contient de nombreuses application en production avec des dépendances fonctionnelles. Dans ce cas il faut pouvoir respecter des contraintes de temps lorsqu'on doit livrer des versions d'application dont d'autres dépendent et qu'on est sur leur chemin critique.
Ce cas de figure n'est pas le plus commun surtout pour de petits projets ou de petites structures. Surtout avec les méthodes agiles ou le périmètre fonctionnel évolue au lieu d'être figé pour une livraison (pas de lots en parallèle).
Le trunk based ou le branching by feature (qui permet le déploiement en continu, comme nos amis de Github ) conviennent mieux.
Mais dans tous les cas faire correspondre un dépôt a un unique composant/projet avec son propre cycle de vie est préférable.
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
La raison est que du code avec des cycles de vie complètement différents est associé à un composant.
Il n'y a que les développeurs SVN pour prétendre le contraire.
Les mêmes qui défendent leur outil en arguant que les branches ne sont pas importantes et qu'on en a pas besoin en agilité, qu'on peut contourner avec le "feature flipping" ou le "branching by abstraction", simplement pour masquer les lacunes de leur outil. Les bonnes pratiques agiles n'empechent pas d'utiliser un bon outil. qui peut le plus peut le moins.
Outre, le fait que ca améliore les performances, le découpage en dépôts permet l'approche par composant: Les composants sont donc ensuite assemblés avec des versions différentes pour former l'application. Ils sont interchangeables.
Ceci renforce aussi la structuration du code, facilite le passage de code entre différentes équipes... Les raisons ne manquent pas.
Bref, c'est une bonne pratique que les équipes sous SVN oublient parfois à leurs dépens...
Concerant ton lien:
Depuis des années nous pratiquons le "trunk based development" dans ma boîte sous Clearcase avant de passer sous Git. D'où l'intérêt de créer un dépôt par composant avec son propre cycle de vie justement.
Les branches par release ne sont intéressantes qu'à partir du moment où plusieurs releases avec des lots de fonctionnalités différentes sont développées en parallèle ou lorsque un SI contient de nombreuses application en production avec des dépendances fonctionnelles. Dans ce cas il faut pouvoir respecter des contraintes de temps lorsqu'on doit livrer des versions d'application dont d'autres dépendent et qu'on est sur leur chemin critique.
Ce cas de figure n'est pas le plus commun surtout pour de petits projets ou de petites structures. Surtout avec les méthodes agiles ou le périmètre fonctionnel évolue au lieu d'être figé pour une livraison (pas de lots en parallèle).
Le trunk based ou le branching by feature (qui permet le déploiement en continu, comme nos amis de Github ) conviennent mieux.
Mais dans tous les cas faire correspondre un dépôt a un unique composant/projet avec son propre cycle de vie est préférable.