Le lien que tu montres semble corroborer mes propos.
Pour Google, il y a des projets complètement différents qui sont géré sous un même dépot Perforce, qui comme SVN
utilise "l'inter-file branching model" voir (Eric Sink paragrahe "two banchin models") mais qui contrairement a SVN sens sort mieux dans le name tracking lors des merge.
Dans ces 2 outils, les branches et les tags sont des répertoires. Brancher est aussi simple que de copier un répertoire.
Git et Hg utilisent l'autre modèle dans lesquelles les branches sont des méta-données gérées par l'outil et sont distribués.
Il est donc impératif d'isoler les modules disjoints dans leur dépôt et de ne réserver le depôt unique que pour le code fortement couplé. C'est pourquoi j'expliquais comment transposer le branching ala SVN sous Git (solution 2)
Après c'est vrai que ce n'est peut-être pas la situation de FB mais si tu me relis bien tu verras que j'avais mis les balises pour les taquiner (trollday).
Pour Clearcase, le schéma que l'auteur présent est celui proposé par la surcouche UCM de Cleracase, mais l'auteur ment en disant que c'est le workflow par défaut. Il est possible, mais le trunk bas est possible puisque ce n'est que la version simplifié du mainline. Qui dit simplifié dit recherche de simplicité. Et en effet c'est préférable. De même qu'il est préferable d'éviter les branches lorsqu'on le peut (http://martinfowler.com/bliki/FeatureBranch.html)en modifiant son architecture (http://martinfowler.com/bliki/BranchByAbstraction.html, http://martinfowler.com/bliki/FeatureToggle.html,...) mais dans les 2 cas ce n'est pas toujours possible.
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Le lien que tu montres semble corroborer mes propos.
Pour Google, il y a des projets complètement différents qui sont géré sous un même dépot Perforce, qui comme SVN
utilise "l'inter-file branching model" voir (Eric Sink paragrahe "two banchin models") mais qui contrairement a SVN sens sort mieux dans le name tracking lors des merge.
Dans ces 2 outils, les branches et les tags sont des répertoires. Brancher est aussi simple que de copier un répertoire.
Git et Hg utilisent l'autre modèle dans lesquelles les branches sont des méta-données gérées par l'outil et sont distribués.
Il est donc impératif d'isoler les modules disjoints dans leur dépôt et de ne réserver le depôt unique que pour le code fortement couplé. C'est pourquoi j'expliquais comment transposer le branching ala SVN sous Git (solution 2)
Après c'est vrai que ce n'est peut-être pas la situation de FB mais si tu me relis bien tu verras que j'avais mis les balises pour les taquiner (trollday).
Pour Clearcase, le schéma que l'auteur présent est celui proposé par la surcouche UCM de Cleracase, mais l'auteur ment en disant que c'est le workflow par défaut. Il est possible, mais le trunk bas est possible puisque ce n'est que la version simplifié du mainline. Qui dit simplifié dit recherche de simplicité. Et en effet c'est préférable. De même qu'il est préferable d'éviter les branches lorsqu'on le peut (http://martinfowler.com/bliki/FeatureBranch.html)en modifiant son architecture (http://martinfowler.com/bliki/BranchByAbstraction.html,
http://martinfowler.com/bliki/FeatureToggle.html,...) mais dans les 2 cas ce n'est pas toujours possible.