Quelles conventions de dénomination utilisez-vous pour les branches et les tags SVN?

Question

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?

Answer 1

J'ai toujours précéder les balises (et généralement, les branches trop) avec la date au format AAAAMMJJ, suivie par une description de l'objet de l'étiquette ou de la branche.

par exemple, 20090326_Release_v6.5 ou 20090326_Post_Production_Update

C'est en vertu de la norme trunk/tags/branches de la hiérarchie de cours.

La date préfixe assure que toutes les balises ou les branches sont affichés dans l'ordre de création, qui est beaucoup plus utile alors juste d'être triées par description si votre analyse par l'intermédiaire d'un gros dossier de balises. Vous voyez le calendrier de quand et pourquoi ils ont été créés (comme les mini-messages de journal).

Answer 2

Eh bien, la ramification est plutôt ouverte, car il y a plusieurs sortes de branches, la désignation d'entre eux peuvent être très différentes.

Il vaut la peine de se souvenir de ce contrôle à la source vous donne. Les noms des balises ne sont pas seulement des "v1.4", c'est "/CashCowProject/tags/v1.4". La dénomination d'une balise "/CashCowProject/tags/CashCowProject-v1.4" est un peu redondant, quoi d'autre pourrait-il être?

Révision de contrôle vous donne également un accès complet aux dates et heures que les étiquettes ont été créées. Révision de contrôle vous donne également des messages de commit qui vous devriez faire usage de, en particulier la première ligne.

Compte tenu de cette information, il n'est pas difficile à réunir une simple vue de vous donner toutes les informations dont vous avez besoin, en provenance de la cohérence et la pertinence des sources, 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 que le nom de la balise est vraiment utile ici c'est le numéro de version. Si vous essayez de mettre toutes les informations dans le nom d'une balise, c'est un peu bavard et je parie qu'il ne sera pas aussi bonne.

Answer 3

Pour une branche, le nom après ce qui est fait. Par exemple, j'ai déménagé notre ORM de LINQ to SQL pour NHibernate et créé une branche appelée "NHibernate". Une fois que vous avez terminé la direction générale et fusionnés dans le tronc, vous pouvez supprimer la branche d'enregistrer des conflits de nommage dans l'avenir. Si vous avez vraiment besoin de récupérer la branche que vous le pouvez, vous avez juste à se plonger à nouveau dans l'histoire et de la restaurer.

Si vous avez une histoire/citation/nombre d'emplois qui sont pertinentes à une branche, je voudrais ajouter qu'il le nom de la branche par exemple. "NHibernate_429" de sorte que vous pouvez facilement faire référence à l'encontre de votre système de suivi. Cependant, je suis toujours aller avec les anglais d'abord, que c'est ce que les gens sont plus réaliste d'aller le consulter lorsqu'il est en cours de développement.

Pour des choses comme des balises, il est difficile de dire ce que vous voulez faire dépend de ce que vous êtes de marquage. Si vous êtes marquage libère alors je voudrais utiliser "Version X. X. X. X" ou quelque chose de simple comme ça. Vous vraiment ne vont pas se soucier de ce que la date ou le numéro de version a été lorsque vous êtes à la recherche de retour pour une version spécifique comme un exemple.

Answer 4

L'ensemble de nos développeurs tâches dans un système de suivi des bogues. Ce système de suivi des bogues a Id associés à chaque tâche.

Donc pour le nom de la branche de n'importe quelle tâche, nous utilisons:

ticketId_TicketSubject

Lorsqu'une branche contient plusieurs ticketIds nous venons de les combiner dans le nom de la branche:

ticketId1_ticketId2_Description

De cette façon, si vous êtes dans un billet et vous voulez savoir à quelle branche de construire, vous pouvez facilement regarder. De même, si vous souhaitez trouver le billet avec votre direction, vous pouvez facilement le trouver trop.

Pour les balises, nous avons balise par le numéro de version de lui-même.

Comme pour l'emplacement de chaque branche. Nous avons une hiérarchie de niveau supérieur comme ceci:

/branches

/tags

/trunk

Puis l'ensemble de nos produits/projets dans chacun d'eux, à l'intérieur de leur propre sous-dossiers.

/trunk/project1/

/branches/project1/TicketId_Description

Answer 5

Ce que nous utilisons (surtout à la suite de la convention acceptée):

projectName
 |
 --trunk
 |
 --tags
 |
 --branches

Sous le tronc, nous avons le tronc principal.

En vertu de balises, nous tag, pour chaque version (à la fois interne, les tests de rejets et de la clientèle de rejets). Il nous suffit d'utiliser le numéro de version, comme le nom de la balise.

Sous les branches, nous avons une branche pour chaque version majeure, nous avons publié (dans notre cas le résultat d'un XP itération). Ceux qui sont nommés, comme la version majeure ("v5.03", "v6.04"). En outre, nous avons à l'interne des branches d'importants changements, ou des versions spéciales. Il y a des noms de forme libre, et le nom est censé dire aux gens ce que la branche représente. Expamples serait "workaround_customerA", "module_x_reorg" etc.