Quelles conventions de dénomination utilisez-vous pour les branches et les tags SVN?
Notre société est en train de créer une convention de nommage pour les branches et les tags SVN, et je ne suis pas à l'aise avec l'idée d'utiliser uniquement la date ou le numéro de build sur les noms de branches/tags.
Je pense que nous avons besoin de noms qui apportent une définition plus précise de ce que représente ce chemin, des efforts déployés, etc.
Que pensez-vous/utilisez-vous?
Je préfixe toujours les balises (et généralement aussi les branches) avec la date au format AAAAMMJJ, suivie d'une description de la fonction de la balise ou de la branche.
par exemple, 20090326_Release_v6.5 ou 20090326_Post_Production_Update
Ceci est bien sûr dans la hiérarchie standard trunk/tags/branches.
Le préfixe de date garantit que toutes les balises ou branches sont affichées dans l’ordre de création, ce qui est beaucoup plus utile que de simplement trier par description si vous parcourez un grand dossier de balises. Vous voyez la chronologie de quand et pourquoi ils ont été créés (comme des messages de mini journal).
Eh bien, les branches sont assez ouvertes, car il y a plusieurs sortes de branches, leur nom peut être très différent.
Rappelez-vous ce que le contrôle de source vous donne. Les noms de balises ne sont pas simplement "v1.4", c'est "/CashCowProject/tags/v1.4". Nommer une balise "/CashCowProject/tags/CashCowProject-v1.4" est un peu redondant, quoi d'autre serait-il?
Le contrôle de révision vous donne également un accès complet aux dates et heures de création des balises. Le contrôle de révision vous fournit également des messages de validation que vous devriez utiliser, en particulier la première ligne.
Compte tenu de toutes ces informations, il n'est pas difficile de créer une vue simple vous donnant toutes les informations dont vous avez besoin, provenant de sources cohérentes et appropriées, telles que:
CashCowProject
v1.4 - 26 March 2009 : With Added whizzbang (more)
v1.3 - 13 February 2009 : Best graphics! (more)
v1.2 - 01 January 2009 : Upgraded security (more)
La seule chose pour laquelle le nom de la balise est vraiment utile est le numéro de version. Si vous essayez de mettre toutes les informations dans un nom de tag, c'est un peu verbeux et je parie que ça ne sera pas aussi beau.
Pour une branche de fonctionnalité, nommez-la après ce qui est fait Par exemple, j'ai déplacé notre ORM de LINQ vers SQL vers NHibernate et j'ai créé une branche appelée "NHibernate". Une fois que vous avez terminé la branche et que vous l'avez fusionnée dans le coffre, vous pouvez supprimer la branche pour enregistrer les conflits de noms à l'avenir. Si vous avez vraiment besoin de récupérer la branche que vous pouvez, il vous suffit de replonger dans l'historique et de le restaurer.
Si vous avez des numéros d’histoire/citation/travail qui sont pertinents pour une branche, je l’ajouterai au nom de la branche, par exemple. "NHibernate_429" afin que vous puissiez facilement le référencer par rapport à votre système de suivi. Cependant, je choisirais toujours l'anglais en premier, car c'est ce à quoi les gens vont se référer de manière plus réaliste quand il est en développement.
Pour des choses comme les tags, il est difficile de dire ce que vous voulez faire, cela dépend de ce que vous taggez. Si vous balisez des versions, utilisez "Release X.X.X.X" ou quelque chose de simple comme ça. Vous ne vous souciez vraiment pas de la date ou du numéro de build lorsque vous recherchez une version spécifique, par exemple.
Toutes nos tâches de développement vont dans un système de suivi des bogues. Ce système de suivi des bogues a des identifiants associés à chaque tâche.
Donc, pour le nom de branche de n'importe quelle tâche, nous utilisons:
ticketId_TicketSubject
Quand une branche contient plusieurs ticketId, nous les combinons simplement dans le nom de la branche:
ticketId1_ticketId2_Description
Ainsi, si vous êtes dans un ticket et que vous voulez savoir quelle branche construire, vous pouvez facilement le rechercher. De même, si vous souhaitez trouver le ticket avec votre agence, vous pouvez également le trouver facilement.
Pour les tags, nous le marquons par le numéro de version lui-même.
En ce qui concerne l'emplacement de chaque branche. Nous avons une hiérarchie de haut niveau comme celle-ci:
/branches
/tags
/trunk
Ensuite, tous nos produits/projets sont placés sous chacun de ceux qui se trouvent dans leurs propres sous-dossiers.
/trunk/project1/
/branches/project1/TicketId_Description
Ce que nous utilisons (principalement suivant la convention acceptée):
projectName
|
--trunk
|
--tags
|
--branches
Sous le coffre, nous avons le coffre principal.
Sous les balises, nous étiquetons chaque version (à la fois les versions internes, de test et les versions client). Là, nous utilisons simplement le numéro de version comme nom de tag.
Sous les branches, nous avons une branche pour chaque version majeure que nous avons publiée (dans notre cas, le résultat d'une itération XP.). Ceux-ci sont nommés comme la version majeure ("v5.03", "v6.04"). De plus, nous avons des branches internes pour les modifications majeures ou les versions spéciales. Leur nom est de forme libre, et le nom est supposé dire aux gens ce que représente la branche. Les exemples seraient "workaround_customerA", "module_x_reorg", etc.
Nous donnons à nos succursales une version ".X", où les balises ont un numéro.
Par exemple, la branche serait Foo-1.2.3.X et les balises seraient Foo-1.2.3.1, Foo-1.2.3.2, etc.
Nous avons également une balise spéciale, Foo-1.2.3.0, qui est créée dès que la branche est créée à partir du tronc, avant toute modification. Ainsi, nous pouvons différencier les branches et les étiquettes de l'état initial à tout moment (car dans quelques jours, le tronc risque d'être différent). Cette pratique a un peu simplifié les fusions et permet de déterminer beaucoup plus facilement le code modifié dans la branche.
Meilleur:
<projectname>_<Year>_<minor>_00
comme:
XYZ_14_01_00