Il y a environ un an et demi, j'ai été chargé de mener une étude pour répondre à cette question. Voici le résumé, basé sur les références étudiées (listées ci-dessous)
http://msdn.microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx
... Choisir la meilleure stratégie de branchement est un exercice d'équilibre. Vous devez compenser les gains de productivité par un risque accru. Un moyen de valider la stratégie choisie consiste à envisager un scénario de changement. Par exemple, si vous décidez d'aligner les branches sur l'architecture système (par exemple, une branche représente un composant du système) et attendez-vous à des modifications architecturales importantes, vous devrez peut-être restructurer vos branches, processus et stratégies associés à chaque modification. Le choix d'une stratégie de branchement inadéquate peut entraîner des frais généraux de processus ainsi que de longs cycles d'intégration et de version qui s'avèrent frustrants pour toute l'équipe ...
http://www.cmcrossroads.com/bradapp/acme/branching/
... L'intégration fréquente et incrémentale est l'un des indicateurs du succès et son absence est souvent une caractéristique de l'échec. Les méthodes actuelles de gestion de projet tendent à éviter les modèles de cascade stricts et à adopter les modèles en spirale de développement itératif / incrémental et de prestation évolutive. Les stratégies d'intégration incrémentielles, telles que Fusionner tôt et souvent et ses variantes, constituent une forme de gestion des risques qui tente d'éliminer les risques plus tôt dans le cycle de vie quand il reste plus de temps pour y faire face. [Booch], [McCarthy] et [McConnell] voient la régularité du rythme entre les intégrations comme un indicateur avancé de la santé d'un projet (comme un "pouls" ou un "battement de coeur").
Une intégration précoce et fréquente permet non seulement de concrétiser les risques plus tôt et en plus petits morceaux, mais aussi de communiquer les changements entre coéquipiers ...
http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
... Dans la plupart des systèmes de contrôle de source, vous pouvez créer des centaines de branches sans aucun problème de performances. c'est la surcharge mentale de garder une trace de toutes ces branches dont vous avez vraiment besoin de vous inquiéter ... La ramification est une bête complexe. Il existe des dizaines de façons de créer des branches, et personne ne peut vraiment vous dire si vous le faites bien ou mal…
http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx
... Il existe de nombreux aspects d'un système à prendre en compte lors de la création d'une branche de code ... Au final, l'objectif est de fournir un bac à sable pour le contexte dans lequel le code est écrit. Comprendre les options disponibles, lorsque chaque option est la mieux adaptée à la situation actuelle et que le coût de ces options vous aidera à décider quand et quand vous souhaitez créer une branche ...
http://www.snuffybear.com/ucm_branch.htm
Remarque: compte tenu des autres références répertoriées ici, l'affirmation de l'auteur selon laquelle "Cet article décrit trois modèles de branchement clés utilisés dans les projets de génie logiciel" ne semble pas justifiée. La terminologie utilisée ne semble pas répandue ( EFIX , Model-1,2,3, etc.).
http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf La
référence présente un exemple intéressant de difficulté à communiquer des stratégies de branchement.
http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
... Restez simple. Travailler directement du coffre est de loin la meilleure approche à mon avis.
Cela ressemble presque à une hérésie lorsque je le tape réellement sur mon écran, mais si vous persistez un instant avec moi, je ne vous montrerai pas seulement pourquoi je pense que cela est essentiel pour un processus Agile, mais je vais vous montrer comment. pour que cela fonctionne ...
... Si je devais fonder mon raisonnement sur un argument solide, ce serait la valeur de l'intégration continue. J'ai blogué sur la valeur de l'EC et les meilleures pratiques du passé. Je suis un assez grand défenseur de CI ...
... Il faut vraiment vous poser une question ici: « Est -ce tous les frais généraux que vous encourons de faire votre stratégie et la fusion compliquée ramification résultant en une valeur réelle qui n'existe pas sur une stratégie plus simple? » ...
.. .Une stratégie que j’ai utilisée avec succès par le passé et que j’ai développée avec le temps. Je vais résumer brièvement ici.
- Tout le monde travaille hors du tronc.
- Branche lorsque vous libérez le code.
- Séparez une version lorsque vous devez créer un correctif pour un code déjà publié.
- Branche pour les prototypes.
...
http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
... Enfin, rappelez-vous qu'il n'y a pas de stratégie idéale de création de branches et de fusions. Cela dépend beaucoup de votre environnement de développement unique ...
http://blog.perforce.com/blog/?cat=62
... Le pire des cas est que vous introduisez un problème de "fusion sémantique", dans lequel le résultat d'une fusion automatique est incorrect, mais compile bien et passe au-delà test, voire même survivre assez longtemps pour être un bogue visible par le client. Eek!
Ajoutant l'insulte à la blessure, car ils peuvent échapper plus longtemps à la détection, les problèmes de fusion sémantique sont plus difficiles à résoudre plus tard, car le changement n'est plus d'actualité pour le développeur à l'origine du changement. (Il est généralement préférable de fusionner les modifications peu de temps après, idéalement par le développeur à l'origine des modifications, si cela s'avère pratique) ...
https://stackoverflow.com/questions/34975/branching-strategies Les
membres de la communauté partagent une expérience différente dans différents projets utilisant différentes stratégies de branchement. Pas de consensus sur le "meilleur" ou le "pire".
http://www.stickyminds.com/s.asp?F=S16454_COL_2
Un résumé succinct des éléments présentés dans http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf.
- http://www.stickyminds.com/s.asp?F=S16511_COL_2
... Il existe trois approches courantes pour décider quand et comment créer une branche:
- Créez la branche de publication lorsque vous êtes "fonctionnalité complète" et prévoyez de résoudre les problèmes de dernière minute sur cette ligne de code. Dans ce cas, la branche de version est en réalité une "ligne de code de préparation de version", comme décrit dans Modèles de gestion de la configuration logicielle , car vous vous attendez à ce qu'il reste encore du travail à faire.
- Changez votre style de travail pour éviter le travail d'intégration final, en dehors de la ligne de développement active.
- Branchez le nouveau travail en créant une branche de tâche et en le fusionnant dans la ligne de développement active une fois la publication terminée.
... Une des raisons de la création de branches est d'isoler le code à la fin d'une publication afin qu'il puisse se stabiliser. L'isolement par branchement masque souvent un problème de qualité qui finira par se traduire par le coût supplémentaire de la maintenance des flux parallèles avant la sortie d'un produit. La ramification est facile. Il est plutôt difficile de choisir un processus qui minimise le coût de la création de branches et de la fusion ... Il est donc important de choisir un processus qui minimise le coût de la création de branches et de la fusion ...
http://nvie.com/posts/a-successful-git-branching-model/ Stratégie orientée Git.
... Nous considérons origine / maître comme la branche principale où le code source de HEAD reflète toujours un état prêt pour la production .
Nous considérons que origine / develop est la branche principale où le code source de HEAD reflète toujours un état avec les dernières modifications de développement livrées pour la prochaine version. Certains appellent cela la "branche d'intégration". C’est ici que sont construits tous les builds nocturnes automatiques ....
http://svnbook.red-bean.com/fr/1.5/svn.branchmerge.html
... les règles de projet varient énormément en ce qui concerne le moment propice pour créer une branche de fonctionnalité. Certains projets n'utilisent jamais de branches de fonctionnalités: les commits vers / trunk sont gratuits. L'avantage de ce système est qu'il est simple: personne n'a besoin de se renseigner sur la création de branches ou la fusion. L'inconvénient est que le code de la ligne de réseau est souvent instable ou inutilisable. D'autres projets utilisent les branches à l'extrême: aucun changement n'est jamais engagé directement dans le coffre. Même les changements les plus insignifiants sont créés sur une branche éphémère, soigneusement examinés et fusionnés dans le coffre. Ensuite, la branche est supprimée. Ce système garantit un coffre exceptionnellement stable et utilisable à tout moment, mais au prix d’ une énorme perte de temps.processus de traitement.
La plupart des projets adoptent une approche à mi-chemin. Ils insistent généralement pour que / trunk compile et passe des tests de régression à tout moment. Une branche de fonctionnalité est requise uniquement lorsqu'un changement nécessite un grand nombre de validations déstabilisantes. Une bonne règle à suivre est de poser cette question: si le développeur travaillait de manière isolée pendant plusieurs jours, puis engageait le grand changement en même temps (de manière à ce que / le tronc ne soit jamais déstabilisé), un changement trop important serait-il à réviser? Si la réponse à cette question est "oui", le changement doit être développé sur une branche. Au fur et à mesure que le développeur applique des modifications incrémentielles à la branche, elles peuvent être facilement examinées par les pairs.
Enfin, la meilleure solution consiste à "synchroniser" une branche de fonctionnalité au fur et à mesure de l'avancement des travaux. Comme nous l'avons mentionné précédemment, travailler dans une succursale pendant des semaines ou des mois est très risqué. les changements de tronc peuvent continuer à affluer, au point que les deux lignes de développement diffèrent tellement que cela peut devenir un cauchemar en essayant de fusionner la branche pour la ramener au tronc.
Il est préférable d’éviter cette situation en fusionnant régulièrement les modifications de la jonction avec la branche. Créez une politique: une fois par semaine, fusionnez les modifications apportées au tronc de la dernière semaine dans la branche ...
http://thedesignspace.net/MT2archives/000680.html
... Cette section du didacticiel Eclipse CVS est basée sur l'article de Paul Glezen sur le site Web Eclipse: Branching with Eclipse et CVS , et est utilisé avec son autorisation, conformément aux conditions de la licence EPL. Les modifications que je suis en train d'apporter à sa version sont principalement de l'étendre avec plus d'images étape par étape et d'explications, et de l'intégrer à mes propres tutoriels pour débutants afin de la rendre plus accessible aux débutants et aux concepteurs. Les développeurs expérimentés préféreront probablement travailler à partir de la version de Paul ...
http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
... Voici quelques modèles de branchement courants:
- Modèle branche par publication: L’une des stratégies de création de branches la plus courante consiste à aligner les branches sur les versions de produits. Une branche contient tous les actifs de développement logiciel pour une seule version. Parfois, les mises à jour doivent être fusionnées d’une version à l’autre, mais elles ne fusionnent généralement jamais. Les branches seront interrompues lors du retrait d'une version.
- Branche par promotion: une autre approche très courante consiste à aligner les branches sur les niveaux de promotion des actifs logiciels. Une version de développement spécifique est divisée en une branche Test, dans laquelle sont effectués tous les tests d'intégration et de système. Une fois les tests terminés, les ressources de développement logiciel sont connectées à la branche Production et sont finalement déployées.
- Branche par tâche: pour éviter le chevauchement des tâches (ou activités) et une perte de productivité, vous pouvez les isoler sur une branche distincte. N'oubliez pas qu'il s'agit de branches à court terme qui doivent être fusionnées dès que la tâche est terminée, faute de quoi l'effort de fusion requis risque de dépasser les avantages de productivité liés à leur création.
- Branche par composant: vous pouvez aligner chaque branche sur l’architecture du système. Dans cette stratégie, vous vous séparez de composants individuels (ou de sous-systèmes). Ensuite, chaque équipe développant un composant décide à quel moment fusionner son code dans la ligne de développement servant de branche d’intégration. Cette stratégie peut fonctionner correctement si l’architecture du système est en place et si les composants individuels ont des interfaces bien définies. Le fait de développer des composants sur des branches permet un contrôle plus fin des ressources de développement logiciel.
- Branche par technologie: une autre stratégie de branchement alignée sur l'architecture du système. Dans ce cas, les branches sont alignées sur les plateformes technologiques. Le code commun est géré sur une branche distincte. En raison de la nature unique des ressources de développement logiciel gérées sur les succursales, elles ne fusionnent probablement jamais ...
http://msdn.microsoft.com/en-us/library/bb668955.aspx
... Reportez-vous aux instructions de branchement et de fusion dans "Instructions de contrôle de code source" de ce guide pour obtenir un résumé des instructions de branchement et de fusion. ... Lors de la création de branches, tenez compte des points suivants:
- Ne branchez pas sauf si votre équipe de développement doit travailler simultanément sur le même ensemble de fichiers. En cas de doute, vous pouvez étiqueter une construction et créer une branche à partir de cette construction ultérieurement. La fusion de branches peut prendre beaucoup de temps et être complexe, surtout s’il ya des changements importants entre elles.
- Structurez vos arbres de branche de sorte que vous n’ayez besoin de fusionner que dans la hiérarchie (haut et bas de l’arbre de branche) plutôt que dans la hiérarchie. Pour créer des branches dans la hiérarchie, vous devez utiliser une fusion sans base, ce qui nécessite une résolution plus manuelle des conflits.
- La hiérarchie de branche est basée sur le parent et l'enfant de branche, qui peuvent être différents de la structure physique du code source sur le disque. Lors de la planification de vos fusions, gardez à l'esprit la structure de branche logique plutôt que la structure physique sur le disque.
- Ne branchez pas trop profondément. Comme il faut du temps pour exécuter chaque fusion et résoudre les conflits, une structure de ramification profonde peut signifier que les modifications dans une branche enfant peuvent prendre beaucoup de temps pour se propager à la branche principale. Cela peut avoir un impact négatif sur les calendriers de projet et augmenter le temps nécessaire pour corriger les bogues.
- Se branche à un niveau élevé et inclut les fichiers source et de configuration.
- Faites évoluer votre structure de ramification au fil du temps.
- La fusion nécessite qu'un ou plusieurs développeurs exécutent la fusion et résolvent les conflits. La source fusionnée doit être minutieusement testée car il n’est pas rare de prendre de mauvaises décisions de fusion susceptibles de déstabiliser la construction.
- La fusion dans la hiérarchie des branches est particulièrement difficile et vous oblige à gérer manuellement de nombreux conflits qui pourraient autrement être traités automatiquement.
La décision de créer une succursale peut être réduite au point de savoir si le coût de la fusion des conflits en temps réel est supérieur aux coûts indirects de la fusion des conflits entre les succursales ...
http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strategy-with-a-subversion-trunk/
- http://kashfarooq.wordpress.com/2010/12/16/bazaar-branching-strategy-with-a-subversion-trunk-revised/
- http://kashfarooq.wordpress.com/2009/11/02/using-bazaar-feature-branches-with-a-subversion-trunk/
- http://kashfarooq.wordpress.com/2009/09/08/bazaar-or-git-moving-away-from-subversion/
... Est-ce que l'une de ces plaintes concernant Subversion vous semble familière?
- Vous êtes informé au hasard que "vous devez exécuter la mise à jour". Vous effectuez ensuite une mise à jour - qui prend beaucoup de temps. Enfin, vous constaterez qu’aucun changement n’a dû être téléchargé.
- Vous êtes informé au hasard que "vous devez exécuter le nettoyage".
- Vous avez d'énormes problèmes de fusion. Par exemple, vous utilisez ReSharper pour renommer une classe, et d’autres ont mis à jour cette classe entre-temps. Vous voyez alors l'erreur de conflit d'arbre redouté (frisson). Ou pire encore, vous renommez un espace de noms complet et un dossier (double frémissement). Maintenant, vous êtes vraiment dans un monde de douleur.
- Vos fusions ont tendance à être de plus en plus manuelles. Vous devez souvent utiliser WinMerge car Subversion n’a pas la moindre idée.
- Vous attendez souvent que Tortoise mette à jour / vérifie les modifications / quoi que ce soit.
J'ai un référentiel de subversion sur ma clé USB. J'ai des conflits d'arbres et je fusionne des problèmes avec ça, et je suis le seul utilisateur!
Le problème principal est la fusion ...
- "Subversion est nul" semble familier. Il est temps d'écouter Joel et Linus ?
http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
discussion sur les meilleures pratiques en matière de stratégie de séparation des libérations dans le cas de systèmes en évolution.
http://branchingguidance.codeplex.com/
"Guide de branchement de Microsoft Team Foundation Server" - document volumineux et détaillé contenant des recommandations adaptées à différents projets: version HTML ici . Preuve que Microsoft ne croit pas en une approche unique pour les stratégies de branchement.
https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
Quelle est la meilleure stratégie de branchement à utiliser lorsque vous souhaitez effectuer une intégration continue? ... La réponse dépend de la taille de votre équipe et de la qualité de votre contrôle de source, ainsi que de votre capacité à fusionner correctement des ensembles de modifications complexes ...
- http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/
une analyse plus détaillée de l'interaction des branches avec l'intégration continue, basée sur une expérience concrète de Hudson / Jenkins - avec quelques références utiles
.. Ma plus grande découverte a été que bien que CI consiste à s'engager, à pousser et à recevoir souvent des commentaires (le cluster de CI vous fournit des commentaires que votre poste de travail ne pourrait jamais vous donner dans le même temps), le véritable puriste CI a en fait une exigence supplémentaire - que l'équipe doit travailler sur la même base ...
Matériaux utilisés
http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
... CVS et SVN décourageaient toute la stratégie de branchement / fusion car ils étaient totalement incapables de le faire ... ... Règle simple: créez une branche de tâche pour chaque nouvelle fonctionnalité ou correction de bug que vous devez implémenter ... Cela peut sembler excessif pour les utilisateurs de SVN / CVS, mais vous savez que tout GDS moderne vous permettra de créer des branches en une seconde, de sorte qu'il n'y a pas de surcharge.
Remarque importante: si vous l'examinez attentivement, vous constaterez que je parle d'utiliser des branches de tâches en tant que listes de modifications riches ...
http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
... La politique de branchement est influencée par le développement objectifs du projet et fournit un mécanisme pour contrôler l’évolution de la base de code. Il existe autant de variantes de stratégie de création de branche que d'organisations utilisant le contrôle de version de Rational ClearCase. Mais il y a aussi des similitudes qui reflètent l'adhésion commune aux meilleures pratiques ...
http://blogs.open.collab.net/svn/2007/11/branching-strat.html
... Le modèle Subversion (ou le modèle open source général plus précisément) correspond à ce qui est présenté dans le modèle de coffre instable .. .
http://en.wikipedia.org/wiki/Trunk_%28software%29
Dans le domaine du développement logiciel, trunk désigne la branche non nommée (version) d'une arborescence de fichiers sous contrôle de révision . Le tronc est généralement censé être la base d'un projet sur lequel le développement progresse. Si les développeurs travaillent exclusivement sur le coffre, celui-ci contient toujours la dernière version du projet, mais peut aussi être la version la plus instable. Une autre approche consiste à séparer une branche du tronc, à mettre en œuvre des modifications dans cette branche et à les fusionner dans le tronc lorsque la branche s'est avérée stable et opérationnelle. En fonction du mode de développement et du commitpolitique, le coffre peut contenir la version la plus stable, la moins stable ou une version intermédiaire.
Le travail principal du développeur a souvent lieu dans le coffre et les versions stables sont branchées, et des corrections de bugs occasionnelles sont fusionnées des branches au coffre. Lorsque le développement des versions futures est effectué dans des branches autres que le coffre, il le fait généralement pour des projets qui ne changent pas souvent ou pour lesquels un changement risque de prendre beaucoup de temps à se développer avant de pouvoir être intégré dans le coffre. .
http://www.mcqueeney.com/roller/page/tom/20060919
... Ce sont les notes d'un webinaire sur les meilleures pratiques de Subversion , mené le 30 août 2006 par CollabNet. ... Deux stratégies organisationnelles: coffre instable ou coffre stable ... ... PREFERER un coffre instable quand c'est possible ...
https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
Dans SVN, le tronc est l'endroit recommandé pour le développement principal et j'utilise cette convention. pour tous mes projets. Cependant, cela signifie que le tronc est parfois instable, voire cassé ... ... ne serait-il pas préférable de faire le "développement sauvage" sur une branche telle que / branch / dev et de ne fusionner que si le build est raisonnable solide?
- ... Le tronc est l'endroit où le développement en cours est censé se produire. Vous ne devriez vraiment pas avoir de problème avec le code "cassé", si tout le monde teste ses modifications avant de les valider. En règle générale, faites une mise à jour (obtenez tous les derniers codes des pensions) après avoir codé vos modifications. Ensuite, construisez et faites des tests unitaires. Si tout est construit et fonctionne, vous devriez être prêt à l'enregistrer ...
- ... Nope trunk n'est pas le meilleur endroit. Au sein de notre organisation, nous suivons toujours cette approche: Trunk contient le code de version, il est donc toujours compilé. Avec chaque nouvelle version / jalon, nous ouvrons une nouvelle branche. Lorsqu'un développeur acquiert un élément, il crée une nouvelle branche dans cette branche de publication et le fusionne dans une branche de version uniquement après l'avoir testé. La branche Release est fusionnée dans le coffre après les tests du système ...
http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
... J'avais l'habitude de travailler sur le coffre car pour tous les projets sur lesquels j'ai travaillé, c'est soit le développeur unique ou l'équipe s'est assurée que l'enregistrement de code par tous avait réussi les tests locaux. Sinon, nous avons créé (nous avons toujours) des branches pour la résolution de bugs, un code volumineux pour de nouvelles fonctionnalités, etc. Il y a
environ 2 mois, j'ai eu une courte session avec Kamal et il m'a partagé l'idée de story / branch . Et alors que mon équipe commençait à se développer avec plus de développeurs, je ressens le besoin d’encourager la création de nouvelles branches et c’est devenu une règle. Pour un projet avec des tests automatisés définis avec la configuration du CI, une jonction stable est garantie et cette pratique peut très bien s’y intégrer.
Nous n'utilisons pas git mais Subversion parce que c'est comme ça que nous avons commencé et nous sommes toujours à l'aise avec ça maintenant (la plupart du temps) ...
http://www.ericsink.com/scm/scm_branches.html
Ceci fait partie d'un livre en ligne intitulé Source Control HOWTO , un guide des meilleures pratiques en matière de contrôle de code source, de contrôle de version et de gestion de la configuration ...
... Eric's Preferred Branching Pratique ... Gardez une malle "fondamentalement instable". Faites votre développement actif dans le coffre dont la stabilité augmente à mesure que vous approchez de la libération. Après la livraison, créez une branche de maintenance et gardez-la toujours très stable ...
... Dans le chapitre suivant, je vais aborder le sujet de la fusion de branches ...
http://marc.info/?l=forrest-dev&m=112504297928196&w=2
Courrier de départ du fil de discussion traitant des stratégies de création de branches pour le projet Apache Forrest
- note actuellement, le projet semble utiliser un modèle de réseau instable avec des branches de version:
- "Le travail de développement est effectué sur le tronc de SVN ... Il existe des" branches de publication "de SVN, par exemple forrest_07_branch." ( directives du projet )
- "Construire les packages de version candidate ... 17. Créer une branche de maintenance dans SVN ..." ( Comment publier )
Documents de branche CVS O'Reilly:
http://commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable
- ... La philosophie de branchement fondamentalement stable stipule que le tronc doit contenir des données de projet toujours prêtes à être libérées ... ... Des variantes plus légères de cette philosophie permettent de fusionner tout ce qui passe les tests unitaires de développeur. tronc. Une telle approche assouplie nécessite la dissociation d'un candidat à la publication et son analyse QA complète avant publication ...
- ... La philosophie, fondamentalement instable, stipule que le tronc doit contenir le code le plus récent, quelle que soit sa stabilité, et que les versions candidates doivent être dérivées pour l'assurance qualité.
... Des variantes plus souples permettent également la création de branches pour le code expérimental, le refactoring et d'autres codes de cas spéciaux. La fusion d'une branche dans le coffre est effectuée par les responsables de la branche. ...
- Remarque la ressource ci-dessus n'apparaît dans aucune des recherches que j'ai effectuées (les instructions relatives à CVS ne sont plus populaires?)
Meilleures pratiques en matière de gestion de la chaîne logistique (article forcé) sur
http://www.perforce.com/perforce/papers/bestpractices.html
... six domaines généraux du déploiement de la gestion de la chaîne logistique, ainsi que des meilleures pratiques générales dans chacun de ces domaines. Les chapitres suivants décrivent chaque élément ...
Espaces de travail, Lignes de code, Branchement, Propagation des modifications, Générations, Processus ...