Subversion: supprimer les anciennes branches de fonctionnalités ou les conserver

Question

J'ai un référentiel de subversion avec la disposition standard, c’est-à-dire trunk / and branches / (et tags /). Lorsque vous travaillez sur un changement plus important, une branche de fonctionnalité est utilisée, régulièrement synchronisée avec le tronc, puis réintégrée dans le tronc (en utilisant 1,5 maintenant). Jolies choses standard.

Je me demande si une telle branche de fonctionnalité, une fois terminée et fusionnée, devrait être conservée ou supprimée. Le livre de subversion semble parfois suggérer qu’il est courant de les supprimer, mais j’ai aussi vu un tas de projets Open Source qui gardent les branches.

Je suis également quelque peu préoccupé par le fait que supprimer une branche rendra plus difficile le suivi des branches existantes, en particulier lorsque des noms potentiellement en double entrent dans le scénario (disons que nous effectuons une recherche-refactorisation à deux reprises), leur historique de validation disparaissant quelque part dans la profondeur. du référentiel, etc.

D'un autre côté, les branches sont très utilisées, en particulier avec la version 1,5, et j'aime bien l'idée de ne pas avoir à parcourir une longue liste de branches inactives pour trouver celles sur lesquelles je travaille actuellement.

Quels sont les avantages et les inconvénients qui me manquent? Que font les gens?

Answer 1

Si vous souhaitez vraiment les supprimer, craignez de les oublier, créez simplement un dossier sous les branches appelé 'inactif' et svn déplacez vos anciennes branches inactives dans ce dossier. C'est peut-être le meilleur des deux mondes pour vous.

Answer 2

Vous pouvez les supprimer en toute sécurité. Leur suppression ne les supprime pas du référentiel, l’espace alloué n’est jamais récupéré, mais l’arborescence de votre projet semble plus épurée.

Answer 3

Je supprime les branches de fonctionnalités au fur et à mesure que nous terminons, car j'aime le manque d'encombrement. Il y a eu une légère confusion de la part de certains autres développeurs, mais depuis que nous enregistrons les numéros de révision des commits dans notre système de suivi des bogues, les choses se sont bien déroulées. Si quelqu'un arrive en disant qu'il ne trouve pas de succursale, il est conseillé d'utiliser l'indicateur -rrevision dans son journal / diff / checkout / tout ce qui est généralement suffisant.

Answer 4

Mon équipe les supprime pour réduire l'encombrement. Ce n'est pas comme si on s'en allait après tout; ils peuvent être récupérés si vous le souhaitez. Vous avez raison de dire qu’il peut être difficile de les retrouver: vous devez connaître le numéro de la révision dans laquelle se trouve la succursale. Par conséquent, vous demandez à votre client de consulter cette révision pour pouvoir visualiser vos fichiers.

Nous utilisons FogBugz pour notre gestion de projet, qui enregistre le moment où les choses ont été validées dans notre référentiel SVN par numéro de révision. Nous pouvons utiliser ceci pour déterminer la révision à laquelle nous devons revenir afin de voir nos fichiers: nous trouvons l'historique des fonctionnalités dans FogBugz, nous cherchons à déterminer les révisions dans lesquelles la branche existait et nous utilisons ces informations pour revenir en arrière.