Meilleure pratique pour fusionner/ne pas fusionner les balises svn

Question

J'ai créé une balise nommée v1.5 sur une branche.Après quelques tests, j'ai trouvé quelques bugs et il semble que je doive propager ces modifications à tag/v1.5.Mais je vois certains commentaires qui ne suggèrent pas une telle pratique de mise à jour ou de fusion d'une balise.

Ma question est de savoir quelle est la meilleure façon de gérer des situations comme celle-ci.Supprimez probablement la balise et recréez-la à partir de la révision de l'en-tête de branche ?

Answer 1

Étiquettes, branches, etc.cela n'a aucun sens pour Subversion lui-même, ce ne sont que des dossiers et vous pouvez faire tout ce que vous voulez.Cependant, il existe de bonnes pratiques et les balises signifient quelque chose que vous ne modifiez jamais.Vous devriez avoir un flux de travail et vous y tenir.

Par exemple, nous réalisons de nouveaux aménagements dans le coffre.Quand c'est prêt, nous créons une branche, comme 1.5, puis créons des balises, comme 1.5.1, 1.5.2, 1.5.3, etc.Nous ajoutons des corrections de bugs et créons de nouvelles balises à partir de celles-ci, nous n'ajoutons pas de nouvelles fonctionnalités aux branches et nous ne modifions jamais les balises.Ensuite, nous fusionnons les corrections de bugs de la branche vers le tronc lorsqu'il y a de nouveaux développements.Il s'agit d'un flux de travail très courant.

Voici un article plus long, ce que j'ai décrit ci-dessus est appelé "modèle de version stable" ici, il y a une bonne image pour vous montrer ce qui se passe où.Il existe également des alternatives et une longue discussion.J'adore ces graphiques, En voici un autre, mais c'est un peu déroutant, les flèches ne doivent pas croiser les balises, les balises doivent toujours être une impasse.

Answer 2

la meilleure pratique est de ne pas supprimer tags en fait, les balises ne sont pas destinées à être touchées, ce ne sont que des étiquettes, alors qu'il est vrai que tout est un dossier dans n'importe quel référentiel svn, la pratique consiste généralement à travailler dessus trunk, mise à jour branches en cas de bugs, et partez tags en tant que marqueurs pour les antécédents de travail antérieurs à titre de référence, les branches peuvent également être utilisées pour un travail séparé, la meilleure pratique est de travailler avec un seul modèle de tronc unique et d'éviter autant que possible les branches (intégration de livraison continue), mais dans votre cas, je le ferais branchez-vous sur la balise et mettez-la à jour, puis fusionnez-la avec le tronc. tags sont censés rester.ce que je ferais, c'est copier le tag dans une branch avec le nom de la branche et effectuez la mise à jour là-bas.Alors je voudrais merge il revient à trunk.pour fusions automatiques il existe un utilitaire sympa pour svn appelé utilitaire de fusion automatique

Google et Facebook ont ​​adopté le développement basé sur le tronc.développement Dans les documents ci-dessus, ces Googleurs ont parlé de travailler sur HEAD et que les enregistrements se produisent à tout moment sur HEAD.Ashish dit trunk à plusieurs reprises vers la fin dans une section de questions-réponses, et il mentionne qu'il évite les branchements pour le développement en cours (rien à voir avec les versions en soi).C'est donc officiel, le développement basé sur le tronc (TBD) est ce que fait Google, et ils le font évoluer !(http://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/)

Answer 3

Les balises dans SVN sont (conventionnellement) un sous-arbre RO.Si vous avez modifié après avoir créé le code de la balise, vous devez créer nouvelle balise à partir du code modifié