Utiliser du branching by abstraction n'a rien à voir avec l'outil de source hein... c'est pas fait pour combler un quelconque manque mais bien pour permettre d'offrir les features autrement ou d'avoir des migrations plus douces. Vraiment.
J'ai jamais dit le contraire. Relis-moi mais j'ai souvent entendu ce discours lorsque des devs SVN en détresse ne se sortaient pas d'un merge:
"Tfacon avec la CI on a plus besoin de branche."
"J'ai vu sur un forum que la feature toogling résolvait ce pb" , pour des applis mobiles niveau sécurité c'est top.
Tu peux appliquer des bonnes pratiques architecturales mais parfois un bon outil vient à la rescousse et les branches deviennent incontournables c'est tout.
Heu, en quoi ? 1 dépôt commun ne va pas dire que tu n'organises rien, bien au contraire.
Tout à fait.
Sauf que parfois des développeurs font des svn cp dasn tous les sens sans réfléchir aux conséquences de leur actes (surtout avec des equipes de projet différentes) et tu te retrouves avec du code d'un module qui n'a rien à faire à cet endroit et là le cauchemar commence pour s'y retrouver. Ca arrive moins si tu as des dépôts disjoints (ou alors à moins de forcer tout ca avec des hooks. SVN est déjà un monstre de perf.)
Alors là faut voir. C'est très variable comme affirmation.
Oui le découpage en composant est une opération délicate. Parfois le code est complètement disjoints et peu couplé.
Dans ce cas c'est largement préférable ... notamment si tu veux migre vers un autre outil par exemple.
Sinon le trunk based development est un workflow et ne dépend pas de l'outil mais du contexte (architecture, type de produit, équipes, ...)
J'ai peut-être mal compris, mais les deux cas permettent le déploiement en continu.
A un moment le trunk based montre ses limites si tu ne peux pas mettre en place le feature toggling.
Tu devras forcément créer des branche d'intégration pour une livraison même en agile (effet mini waterfall avec scrum décrit ici par exemple).
Le seul moyen de déployer en continu de manière fiable est de garder ton trunk toujours propre et d'implémenter chaque feature dans sa branche (parfois locale pour les DVCS) puis de l'intégrer et la livrer dès qu'elle est prête (cf lien sur Github plus haut) et non pas groupée avec d'autre lors de la prochaine livraison (sprint par exemple).
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
J'ai jamais dit le contraire. Relis-moi mais j'ai souvent entendu ce discours lorsque des devs SVN en détresse ne se sortaient pas d'un merge:
"Tfacon avec la CI on a plus besoin de branche."
"J'ai vu sur un forum que la feature toogling résolvait ce pb" , pour des applis mobiles niveau sécurité c'est top.
Tu peux appliquer des bonnes pratiques architecturales mais parfois un bon outil vient à la rescousse et les branches deviennent incontournables c'est tout.
Sauf que parfois des développeurs font des svn cp dasn tous les sens sans réfléchir aux conséquences de leur actes (surtout avec des equipes de projet différentes) et tu te retrouves avec du code d'un module qui n'a rien à faire à cet endroit et là le cauchemar commence pour s'y retrouver. Ca arrive moins si tu as des dépôts disjoints (ou alors à moins de forcer tout ca avec des hooks. SVN est déjà un monstre de perf.)
Sinon le trunk based development est un workflow et ne dépend pas de l'outil mais du contexte (architecture, type de produit, équipes, ...)
A un moment le trunk based montre ses limites si tu ne peux pas mettre en place le feature toggling.
Tu devras forcément créer des branche d'intégration pour une livraison même en agile (effet mini waterfall avec scrum décrit ici par exemple).
Le seul moyen de déployer en continu de manière fiable est de garder ton trunk toujours propre et d'implémenter chaque feature dans sa branche (parfois locale pour les DVCS) puis de l'intégrer et la livrer dès qu'elle est prête (cf lien sur Github plus haut) et non pas groupée avec d'autre lors de la prochaine livraison (sprint par exemple).