Créer une branche ou ne pas créer une branche ? Voilà une question intéressante. Ce chapitre vous a montré jusqu'à maintenant force détails quant aux créations de branches et aux fusions, des sujets qui ont historiquement été la plus grande source de confusion pour les utilisateurs. Comme si l'enchainement mécanique des actions qui sont mises en œuvre dans la création et la fusion de branches n'était pas assez compliqué, quelques utilisateurs restent à se demander si cela vaut le coup de créer une branche ou pas. Comme vous l'avez appris, Subversion gère les scénarios classiques de création et gestion de branches. Ainsi, la décision de créer ou pas une branche d'un projet ne relève pas de critères techniques. C'est davantage les impacts sociaux qui pèsent le plus dans la décision. Examinons quelques avantages et inconvénients d'utiliser des branches dans un projet logiciel.

Le bénéfice le plus évident de travailler sur une branche est l'isolation. Les modifications faites à la branche n'affectent pas les autres lignes de développement du projet ; les modifications des autres lignes n'affectent pas la branche. Dans un certain sens, une branche peut servir de terrain d'expérimentation de nouvelles fonctionnalités, de correction pour des bogues complexes, des réécritures majeures du code, etc. Peu importe la quantité de choses cassées dans la branche de Sally, Harry et le reste de l'équipe peuvent continuer leur travail sans entrave, en dehors de la branche.

Les branches fournissent aussi un mécanisme très élégant pour organiser les modifications qui sont reliées entre elles dans des ensembles immédiatement reconnaissables. Par exemple, les modifications qui résolvent complètement un bogue particulier peuvent se trouver dans une liste de révisions dont les numéros ne se suivent pas. Vous pouvez les énoncer comme « les révisions 1534, 1543, 1587 und 1588 ». Vous les indiquerez sûrement à la main (ou autrement) dans le système de suivi de bogues qui prend en compte ce bogue. Lorsque vous porterez cette correction de bogue vers d'autres versions du produit, vous devrez vous assurer que vous n'oubliez aucune révision. Mais si ces modifications ont toutes été faites dans la même branche, vous pourrez vous référer uniquement à cette branche, par son nom, dans les conversations, dans les commentaires du système de suivi de bogues et lorsque vous portez les modifications ailleurs.

L'inconvénient des branches, cependant, c'est que cette isolation forte qui les rend si utiles peut parfois aller à l'encontre du besoin de collaboration de l'équipe de projet. En fonction des habitudes de travail de vos collègues, les modifications faites à votre branches ne recevront peut-être pas toutes les revues, critiques et tests que subissent les changements de la ligne principale de développement. L'isolation de la branche peut encourager les utilisateurs à oublier certaines bonnes pratiques de la gestion de versions, entrainant un historique des versions difficile à exploiter a posteriori. Les développeurs de branches à longue durée de vie doivent parfois travailler beaucoup plus dur pour s'assurer que la direction vers laquelle évolue leur branche isolée est bien en harmonie avec la direction prise par leurs collègues dans la ligne de développement principale. Maintenant, ces inconvénients peuvent s'avérer sans objet si le développement de la branche consiste justement à explorer une nouvelle souche du logiciel dont le résultat n'a pas vocation à réintégrer la ligne de développement principale (l'application stricte des politiques de développement ne doit pas freiner l'innovation !). En tout état de cause, les projets retirent en général un bon bénéfice d'une approche méthodique dans la gestion de versions où le code et les modifications font l'objet d'un passage en revue et de compréhension par plus d'un membre de l'équipe.

En fin de compte, nous ne proclamons pas qu'il n'y a aucun inconvénient technique à créer des branches. Pardonnez-nous de « diverger » quelque peu dans ce paragraphe. Si vous réfléchissez bien, à chaque fois que vous extrayez une copie de travail Subversion, vous créez en quelque sorte une branche de votre projet. C'est une branche d'une sorte un peu spéciale, qui ne réside que sur la machine cliente, pas dans le dépôt. Vous synchronisez cette branche avec les modifications faites dans le dépôt par la commande svn update (qui agit d'une certaine manière comme une version simplifiée de la commande svn merge ^[47]. Vous réintégrer effectivement la branche à chaque fois que vous lancez svn commit. Ainsi, dans un certain sens, les utilisateurs de Subversion créent des branches et les fusionnent sans arrêt. Compte tenu des similitudes entre la mise à jour et la fusion, il n'est pas étonnant que les points durs de Subversion (la gestion des renommages des fichiers et de dossiers ainsi que les conflits d'arborescences) soient aussi problématiques pour les opérations svn update et svn merge. Malheureusement, svn merge souffre encore plus, précisément parce que, alors que svn update n'est qu'un cas particulier, simplifié, d'une opération de fusion, une véritable opération de fusion Subversion n'est pas un cas particulier ou simplifié. C'est pourquoi les opérations de fusion sont beaucoup plus lentes de les mises à jour, demandent d'avoir un traçage de l'historique (via la propriété svn:mergeinfo que nous avons abordée dans ce chapitre) et des calculs sur cet historique, introduisant généralement beaucoup d'occasions pour que quelque chose se passe de travers.

Créer une branche ou ne pas créer une branche ? Finalement, cela dépend des besoins de votre équipe pour trouver le juste équilibre entre le travail collaboratif et l'isolation.