Subversion : suppression des anciennes branches de fonctionnalités ou maintien de celles-ci

Question

J'ai un dépôt subversion avec la disposition standard, c'est-à-dire trunk/ et branches/ (et tags/). Lorsque je travaille sur un changement plus important, une branche de fonctionnalité est utilisée, régulièrement synchronisée avec le tronc, et plus tard réintégrée dans le tronc (j'utilise 1.5 maintenant). C'est plutôt standard.

Ce que je me demande, c'est si une telle branche de fonctionnalité, une fois terminée et fusionnée, doit être conservée ou supprimée. Le livre de subversion semble parfois suggérer qu'il est courant de les supprimer, mais j'ai également vu un tas de projets Open Source qui conservent les branches.

Je suis également quelque peu préoccupé par la façon dont la suppression d'une branche rendra plus difficile le suivi des branches qui ont existé, en particulier lorsque des noms potentiellement dupliqués entrent dans le scénario (disons que nous recherchons-refactor deux fois), leurs historiques de commit disparaissant quelque part dans la profondeur du dépôt, etc.

D'un autre côté, les branches sont très utilisées, surtout depuis la version 1.5, et j'aime l'idée de ne pas avoir à fouiller dans une grande 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 avez vraiment peur de les supprimer, de peur qu'ils ne soient oubliés, créez simplement un dossier sous les branches appelé "inactif" et svn move vos anciennes branches inactives dans ce dossier. Cela pourrait être le meilleur des deux mondes pour vous.

Answer 2

Vous pouvez les supprimer en toute sécurité. Les supprimer ne les supprime pas du référentiel, l'espace alloué n'est jamais récupéré, mais cela donne à votre arborescence de projets un aspect plus propre.

Answer 3

J'ai supprimé les branches de fonctionnalités au fur et à mesure que nous avons terminé, car j'aime le manque de désordre. Il y a eu une petite confusion de la part de certains autres développeurs, mais comme nous enregistrons les numéros de révision des commits dans notre système de suivi des bogues, tout s'est bien passé. Si quelqu'un vient en disant qu'il ne peut pas trouver une branche, conseillez-lui d'utiliser la fonction -rrevision sur leur journal/diff/checkout/quelque chose est généralement tout ce qui est nécessaire.

Answer 4

Mon équipe les supprime pour éviter le désordre. Ce n'est pas comme s'ils disparaissaient après tout ; ils peuvent être récupérés si on le souhaite. Vous avez raison de dire qu'il peut être difficile de les retrouver : vous devez connaître un numéro de révision où la branche existait et vous dites à votre client de regarder cette révision pour voir vos fichiers.

Nous utilisons FogBugz pour notre gestion de projet, qui garde la trace de la date à laquelle les éléments ont été livrés à notre dépôt SVN par numéro de révision. Nous pouvons l'utiliser pour déterminer à quelle révision nous devons revenir pour voir nos fichiers : nous trouvons l'historique des fonctionnalités dans FogBugz, nous cherchons à déterminer à quelles révisions la branche a existé, et nous utilisons cette information pour revenir en arrière.