L'utilisation appropriée des Tags dans SCM

Question

Mes collègues et moi avons un argument sur la valeur et de l'utilisation des mots clés dans les systèmes de presse / SCM. Nous cherchons à la communauté StackOverflow à mettre dans leurs pensées pour nous aider à résoudre le problème.

Un côté affirme que les étiquettes sont un ajout précieux à la gestion des versions. Un exemple de leur utilisation: nous faisons une version Maven, ce qui en fait une nouvelle balise (appeler 1.0) qui est instantané de code utilisé pour cette version. Cette balise doit être une branche READONLY. Lorsqu'un bug doit être corrigé, nous pouvons faire une copie de l'étiquette dans une nouvelle direction (appeler 1.1). Corrections de bugs y aller. Ces correctifs peuvent être fusionnés dans le tronc afin que la principale branche dev obtient les corrections de bugs. Enfin, 1.1 est libéré et une étiquette 1.1 est automatiquement créé. Ce cycle se poursuit. Le principal avantage ici de la balise est que si vous avez besoin de rééditer la version 1.0 pour une raison quelconque, vous pouvez simplement libérer la balise 1.0 avec la confiance qu'il n'a jamais été altéré par personne. En outre, en disant « Tag version 1.0 » est plus propre que de dire « révision de la version 1 de la branche 1.0 qui est la version 1.0 d'origine sans les correctifs ».

Les autres revendications secondaires que les étiquettes ne fournissent pas un avantage précieux, en particulier dans un système comme Subversion avec les révisions globales, qui agissent comme une marque dans le CVS. De plus, Subversion ne donne un avertissement lors de la validation d'une marque; il ne se limite pas réellement. Leur méthode se développe dans le coffre et à la libération que vous feriez une branche appelée 1.0. Vous continuerions des corrections de bugs dans le coffre et si vous avez besoin de rééditer les corrections de bugs à la production, vous souhaitez les fusionner en 1.0 Direction et RÉÉDITION 1.0. À un moment donné, peut-être après des problèmes importants ou caractéristiques dans le coffre, vous souhaitez libérer et faire Direction 1.1. continue le cycle. Si vous avez besoin de sortir la version 1.0 d'origine, vous auriez à vérifier Branch 1.0 révision 1.

Il est clair que les méthodes de travail. Je voudrais entendre les réflexions sur la méthode est préférée et pourquoi de la communauté.

Edit: Je suis un peu inquiet que la « meilleure » dépend du système SCM sous-jacent. Soit régler sur Subversion pour obtenir des réponses ou, si possible, garder agnostique SCM.

Answer 1

D'un point de vue SCM agnostique, une balise est très différent d'une révision.

Les deux peuvent être mises en œuvre de la même manière, les deux représente une « ligne de temps », mais leur objectif est différent:

• une balise représente une immuable état où tous les fichiers sont référencés par un identifiant unique. Il est un nom représentant beaucoup de choses mais surtout un état stable, ...)
• une révision représente une transaction commit ( pas tous SCM ont les , en particulier les anciens avec une «approche fichier par fichier). Tous les commits ne représentent pas un état « stable » (comme dans « compilation » ou avec succès « exécuter »). Ils sont juste un nouvel élément de l'histoire mondiale.

Le problème avec SVN est que la révision, l'étiquette et les branches sont tous mis en œuvre le même.
Mais je préfère encore l'option où une étiquette est utilisée comme "lecture seule" branche .

Answer 2

Dans mes tags d'opinion sont utiles. Il y aura des moments à un moment donné dans la vie du projet que vous rencontrez un bug ou un changement et que vous voulez savoir s'il était là, dans une version précédente. Il y aura des raisons pour comparer le code d'une version à l'autre pour mesurer l'efficacité à la fois en performance et en fait le développement du code.

Bien sûr, il y a une chance que vous pouvez visser, mais il peut toujours être annulée. Il n'y a vraiment aucune raison de ne pas, et il y a plusieurs raisons pour lesquelles il pourrait être utile à l'avenir. Pour moi, c'est un doux euphémisme.

Je suis d'accord que vous devez également utiliser des branches et de faire votre développement là-bas, mais quand vous relâchez en fait quelque chose, faites une étiquette sur elle.

Answer 3

Oui, vous voulez utiliser des balises.

Pensez à une étiquette comme une simple étiquette ou un nom pour une révision particulière. Il est très utile dans mon expérience pour marquer les étapes importantes dans un projet, que ce soit pour la mise en production ou même pour les versions intermédiaires d'assurance qualité. Vous souhaitez souvent revenir en arrière dans le temps et voir le code source pour une version particulière.

Si tu branche lors de la libération, vous pouvez toujours comprendre ce qui a été publié la révision à la production, mais cela est une sorte de douleur par rapport à simplement regarder une étiquette. Si vous ne l'utilisez pas les branches de libération, alors il sera facile de perdre la trace dont la révision a été utilisé pour créer une version particulière.

Le problème avec svn est qu'il brouille la distinction entre les balises et les branches. Tout le monde peut toujours engager à une étiquette, il est donc pas garantie fixe / immuable. Dans d'autres VCS comme PVCS, un « tag » est inchangeable. Vous pouvez adopter une convention d'équipe pour éviter commits aux étiquettes, ou même peut-être utiliser des crochets engager pour éviter commits à des balises.

Answer 4

Nous utilisons des étiquettes (étiquettes) lors de la création de nouvelles lignes de base. Nous le faisons une fois par semaine, mais certaines équipes le faire même plusieurs fois par jour.

Le point (pour nous) est toujours en vous assurant de la nouvelle ligne de base est stable: il est donc non seulement une construction, est une construction qui passe toute la suite de tests, plusieurs heures de tests automatisés ainsi que ceux d'exploration potentiellement manuelles aussi

Ensuite, la ligne de base est utilisé comme point de départ pour toutes les tâches au cours de la prochaine itération: chaque nouvelle tâche est une nouvelle branche à partir de la ligne de base, qui est connu pour être stable pour tout ce qui est cassé dans la tâche devrait être facile de tracer l'intérieur la tâche elle-même.

Normalement, nous mettons uniquement des étiquettes (étiquettes) sur la branche principale (ou tronc ou maître en fonction de votre goût SMC) qui est le point d'intégration pour toutes les autres branches.

Lorsque nous libérons un produit officiel, nous créons une « branche de sortie pour lui » il ne recevra alors que les nouveaux correctifs reste sur le développement « principal ». Ensuite, ces « branches d'entretien » (je l'espère seulement un ou deux à la fois) peuvent être étiquetés aussi.

Answer 5

Je me plais à penser sur les balises comme « juste un nom de fantaisie pour une révision ». J'ai toujours pensé à eux de cette façon, et ils sont dans IIRC mercurial cela. Dans la subversion Cependant, comme vous le dites, ils sont en effet (bon marché) des copies de coffre / * à étiquettes / fantaisie-name /

Honnêtement, je combine les deux stratégies pour des résultats optimaux: tag et branche lors de la libération. Votre balise est appelée 1.0.0, branche 1.0-MAINT. Bugfixes vont dans les branches, et les versions de correction de bugs sont des balises à nouveau (1.0.1 peut, par une étiquette destinée à un alias 1.0-MAINT à un certain point.)

Ne pas oublier cependant que les balises et les branches dans la subversion sont en fait la même chose: des copies bon marché. La seule différence entre eux est la sémantique que vous / votre équipe leur attribue, il assez se résume bien vers le bas pour amener les gens à se mettre d'accord sur une méthode particualr et tenir à cette (peut être exécuté sur le serveur, par exemple interdisant commits dans les balises / sauf pour les coordinateurs de libération, etc.)

Le problème que je vois bien que la deuxième approche est: comment allez-vous faire une distinction facile entre le logiciel dans le domaine si vous RÉÉDITION 1.0? Cela signifie que vous pouvez avoir un 1.0 et un autre 1.0 fait référence à une base de code différent ....

Answer 6

instantanés de Immuable code source d'un projet (et exécutable) sont très précieux pour faire des essais de toute nature, que ce soit le test structuré ou utilisation terrain. Pour les tests structurés, vous allez être créer des données qui pourraient être des mois ou des années dans référencés l'avenir. Chaque fois que vous revisitez que les données, la loi de Murphy dit que vous aurez besoin de savoir quel code il vient et à moins que vous êtes allé à la peine de citer un aperçu particulier du code source, il sera impossible de dire avec confiance ce code source correspond à que les données de test.

Je ne peux pas vous dire combien de fois quelqu'un est venu me dire: « Ce code de microcontrôleur ne fonctionne pas, pouvez-vous aider? » et je leur demande: « Quelle version utilisez-vous? » et ils disent: « Je ne suis pas sûr » parce qu'ils ne font pas une bonne gestion de la libération (à tout le moins mettre un autocollant sur l'appareil, mieux de mettre les informations dans l'EEPROM versioning interrogeable en temps réel). >: (

Answer 7

Dans SVN, la différence technique entre l'aide d'une étiquette et le suivi d'une révision est nulle. Je me trouve en minimisant l'utilisation de l'étiquette basée sur la façon dont la mise en œuvre de SVN est tout simplement une copie pas cher et encombre votre « espace de structure ».

La vraie différence vient quand communication une référence particulière à une grande équipe de développeurs. Le suivi des révisions apporte une couche d'abstraction supplémentaire qui peut devenir une source d'erreurs. Et comme nous sommes tous conscients, quand vous avez affaire à des développeurs 50+, toute source d'erreur deviendra une source de confusion et de temps perdu. Une étiquette bavard peut éliminer la confusion et éliminer tout doute quant à ce que le but d'une ligne de base est.

Answer 8

Je combine les deux approches. Chaque fois que vous faites une sortie, étiqueter. Mots-clés ne doivent pas changer, de sorte que la présence d'une étiquette « 1.0.0 » est un indicateur que vous ne devriez pas essayer de libérer quoi que ce soit d'autre que 1.0.0.

En même temps, quand il est venu le temps de faire 1.0.0, je le mettrais sur une branche 1.0. Ainsi, le flux est: tronc de branche à 1,0, ce nouveau tag 1.0 comme 1.0.0, et le déploiement. Ensuite, des corrections de bugs peuvent être effectués sur la branche 1.0 (pour éviter de se mélanger avec tout développement 1.1 qui peuvent déjà Ciblée être maintenant sur le tronc) et fusionné dans le tronc. Chaque version de la 1,0 fixe est marqué comme 1.0.x de la branche 1.0. Ceci est essentiellement l'approche que nous utilisons au travail avec Perforce, et qui est très semblable en effet Subversion. (En lisant les réponses, je pense qu'il est pratiquement identique à la recommandation de Vincent)

En ce qui concerne le commentaire sur les balises étant redondant parce que vous avez les numéros de révision --- qui est en grande partie vrai, sauf que les étiquettes précisent également une portée: à savoir les fichiers dans le référentiel sont couverts par l'étiquette. Vous pouvez raisonnablement demander à quelqu'un de regarder /svn/proj1/tag/1.0.0 et ils sont à la recherche immédiatement à un espace de travail cohérent. Si vous leur demandez de regarder la révision X, ils doivent d'abord examiner la révision X pour voir qu'il était en train de changer (par exemple) / svn / proj1 / tronc / Makefile et donc en déduire que / svn / proj1 / trunk / @ X est ce que ils devraient regarder. Qu'advient-il si la révision X touché les fichiers proj1 et proj2? Ce qui est du mal de cours, mais strictement parlant, vous devriez dire / svn / proj1 / trunk / @ X. Et où est la liste des numéros de révision stockée? Comment savons-nous que X 1.0.0 est une révision? Il devrait à mon humble avis être possible de déterminer que seulement à partir du référentiel.

Dans les systèmes tels que Git, les balises et les branches sont encore fondamentalement la même chose (seulement des références à la base de données objet), mais le convention est que refs tag ne changent pas, et refs branche font ( et de préférence avec une contrainte spécifique sur la façon dont ils changent). Perforce a aussi des « étiquettes » qui sont des moyens de regrouper un ensemble de révisions de fichiers ensemble indépendamment d'un changelist; qui est essentiellement une étiquette, mais plus confus: historiquement, nous avons utilisé des numéros de Changelist (équivalent à des numéros de révision de Subversion) avec le nom qualifié de la branche sur laquelle ils devraient être à identifier les versions. Les deux sont presque identiques toute façon, alors voici je suppose que TMTOWTDI.