[svn] Que signifient "branch", "tag" et "trunk" dans les dépôts Subversion?



7 Answers

Tout d'abord, comme le soulignent @AndrewFinnell et @ KenLiu, dans SVN, les noms de répertoires eux-mêmes ne signifient rien - "tronc, branches et balises" sont simplement une convention commune qui est utilisée par la plupart des dépôts. Tous les projets n'utilisent pas tous les répertoires (il est assez commun de ne pas utiliser de "balises"), et en fait, rien ne vous empêche de les appeler comme vous le souhaitez, bien que rompre les conventions soit souvent déroutant.

Je vais décrire probablement le scénario d'utilisation le plus courant des branches et des balises, et donner un exemple de scénario de la façon dont ils sont utilisés.

  • Tronc : Le principal domaine de développement. C'est là que votre prochaine version majeure du code vit, et a généralement toutes les nouvelles fonctionnalités.

  • Branches : Chaque fois que vous publiez une version majeure, une branche est créée. Cela vous permet d'effectuer des corrections de bogues et de créer une nouvelle version sans avoir à publier les nouvelles fonctionnalités, éventuellement inachevées ou non testées.

  • Étiquettes : Chaque fois que vous publiez une version (version finale, version candidate (RC) et version bêta), vous en faites une balise. Cela vous donne une copie ponctuelle du code tel qu'il était à cet état, ce qui vous permet de revenir en arrière et de reproduire des bogues si nécessaire dans une version antérieure, ou de rééditer une version antérieure exactement comme elle l'était. Les branches et les balises dans SVN sont légères - sur le serveur, il ne fait pas une copie complète des fichiers, juste un marqueur indiquant "ces fichiers ont été copiés lors de cette révision" qui ne prend que quelques octets. Dans cet esprit, vous ne devriez jamais être préoccupé par la création d'un tag pour tout code publié. Comme je l'ai dit plus tôt, les balises sont souvent omises et à la place, un journal des modifications ou un autre document clarifie le numéro de révision lorsqu'une version est faite.

Par exemple, disons que vous démarrez un nouveau projet. Vous commencez à travailler dans "trunk", sur ce qui sera finalement publié en version 1.0.

  • trunk / - version de développement, bientôt 1.0
  • branches / - vide

Une fois la version 1.0.0 terminée, vous branchez la ligne de réseau dans une nouvelle branche "1.0" et créez une balise "1.0.0". Maintenant, travailler sur ce qui sera finalement 1.1 continue dans le coffre.

  • trunk / - version de développement, bientôt 1.1
  • branches / 1.0 - version 1.0.0
  • tags / 1.0.0 - 1.0.0 version

Vous rencontrez des bogues dans le code, et les corrigez dans le tronc, puis fusionnez les corrections sur la branche 1.0. Vous pouvez également faire le contraire, et corriger les bogues dans la branche 1.0, puis les fusionner de nouveau vers le tronc, mais généralement les projets s'en tiennent à la fusion à sens unique seulement pour réduire le risque de manquer quelque chose. Parfois, un bug ne peut être corrigé que dans 1.0 car il est obsolète dans 1.1. Cela n'a pas vraiment d'importance: vous voulez seulement vous assurer que vous ne libérez pas 1.1 avec les mêmes bogues qui ont été corrigés dans la version 1.0.

  • trunk / - version de développement, bientôt 1.1
  • branches / 1.0 - version 1.0.1 à venir
  • tags / 1.0.0 - 1.0.0 version

Une fois que vous avez trouvé assez de bogues (ou peut-être un bug critique), vous décidez de faire une version 1.0.1. Donc vous faites un tag "1.0.1" à partir de la branche 1.0, et libérez le code. À ce stade, le tronc contiendra ce qui sera 1.1, et la branche "1.0" contiendra le code 1.0.1. La prochaine fois que vous diffuserez une mise à jour 1.0, ce sera 1.0.2.

  • trunk / - version de développement, bientôt 1.1
  • branches / 1.0 - version 1.0.2 à venir
  • tags / 1.0.0 - 1.0.0 version
  • tags / 1.0.1 - 1.0.1 version de publication

Finalement, vous êtes presque prêt à lancer la version 1.1, mais vous voulez d'abord faire une version bêta. Dans ce cas, vous faites probablement une branche "1.1" et une balise "1.1beta1". Maintenant, travailler sur ce qui sera 1.2 (ou 2.0 peut-être) continue dans le tronc, mais le travail sur 1.1 continue dans la branche "1.1".

  • trunk / - version de développement, bientôt 1.2
  • branches / 1.0 - version 1.0.2 à venir
  • branches / 1.1 - version 1.1.0 à venir
  • tags / 1.0.0 - 1.0.0 version
  • tags / 1.0.1 - 1.0.1 version de publication
  • tags / 1.1beta1 - 1.1 beta 1 version

Une fois que vous avez sorti la finale 1.1, vous faites une balise "1.1" de la branche "1.1".

Vous pouvez également continuer à conserver la version 1.0 si vous le souhaitez, en transférant les corrections de bogues entre les trois branches (1.0, 1.1 et trunk). Le point important est que pour chaque version principale du logiciel que vous gérez, vous avez une branche qui contient la dernière version du code pour cette version.

Une autre utilisation des branches est pour les fonctionnalités. C'est là que vous branchez le tronc (ou l'une de vos branches de publication) et que vous travaillez sur une nouvelle entité de manière isolée. Une fois la fonctionnalité terminée, vous la fusionnez et supprimez la branche.

  • trunk / - version de développement, bientôt 1.2
  • branches / 1.1 - version 1.1.0 à venir
  • branches / ui-rewrite - branche caractéristique expérimentale

L'idée de cela est quand vous travaillez sur quelque chose de perturbateur (qui pourrait retarder ou interférer avec d'autres personnes de faire leur travail), quelque chose d'expérimental (qui peut même ne pas entrer), ou peut-être juste quelque chose qui prend du temps (et vous avez peur si vous tenez une version 1.2 lorsque vous êtes prêt pour la branche 1.2 à partir du tronc), vous pouvez le faire isolément dans une branche. Généralement, vous le tenez à jour avec le tronc en y intégrant des modifications, ce qui facilite la réintégration (fusionner vers le tronc) lorsque vous avez terminé.

Notez également que le schéma de gestion des versions que j'ai utilisé ici en est un parmi tant d'autres. Certaines équipes feraient des corrections de bogues / versions de maintenance comme 1.1, 1.2, etc., et des changements majeurs comme 1.x, 2.x, etc. L'utilisation ici est la même, mais vous pouvez nommer la branche "1" ou "1" .x "au lieu de" 1.0 "ou" 1.0.x ". (À part, le versioning sémantique est un bon guide sur comment faire les numéros de version).

Question

J'ai beaucoup vu ces mots autour des discussions de Subversion (et je suppose que c'est le référentiel général). J'ai utilisé SVN pour mes projets ces dernières années, mais je n'ai jamais compris le concept complet de ces répertoires.

Que signifient-ils?




Tag = une tranche définie dans le temps, généralement utilisée pour les versions

Je pense que c'est ce que l'on entend généralement par "tag". Mais dans Subversion:

Ils n'ont pas vraiment de signification formelle. Un dossier est un dossier à SVN.

ce que je trouve plutôt confus: un système de contrôle de révision qui ne sait rien sur les branches ou les tags. Du point de vue de la mise en œuvre, je pense que la façon de créer des «copies» de Subversion est très intelligente, mais je dois savoir que c'est ce que j'appellerais une abstraction qui fuit .

Ou peut-être que j'utilise CVS depuis trop longtemps.




Ils n'ont pas vraiment de signification formelle. Un dossier est un dossier à SVN. Ils sont un moyen généralement accepté d'organiser votre projet.

  • Le coffre est l'endroit où vous gardez votre ligne principale de développement. Le dossier de la branche est l'endroit où vous pouvez créer, eh bien, les branches, qui sont difficiles à expliquer dans un court message.

  • Une branche est une copie d'un sous-ensemble de votre projet sur lequel vous travaillez séparément du tronc. Peut-être que c'est pour des expériences qui pourraient ne pas aller n'importe où, ou peut-être pour la prochaine version, que vous allez fusionner plus tard dans le coffre quand il devient stable.

  • Et le dossier des balises permet de créer des copies balisées de votre référentiel, généralement lors de la validation des points de contrôle.

Mais comme je l'ai dit, SVN, un dossier est un dossier. branch , trunk et tag sont juste une convention.

J'utilise le mot 'copier' libéralement. SVN ne fait pas réellement des copies complètes des choses dans le dépôt.




En général (vue agnostique de l'outil), une branche est le mécanisme utilisé pour le développement parallèle. Un SCM peut avoir de 0 à n branches. Subversion a 0.

  • Trunk est une branche principale recommandée par Subversion , mais vous n'êtes aucunement obligé de la créer. Vous pouvez l'appeler 'main' ou 'releases', ou n'en pas avoir du tout!

  • La branche représente un effort de développement. Il ne devrait jamais être nommé après une ressource (comme 'vonc_branch') mais après:

    • un objet 'myProject_dev' ou 'myProject_Merge'
    • un périmètre de version 'myProjetc1.0_dev' ou myProject2.3_Merge 'ou' myProject6..2_Patch1 '...
  • Tag est un instantané des fichiers afin de revenir facilement à cet état. Le problème est que tag et branche sont les mêmes dans Subversion . Et je recommanderais certainement l'approche paranoïaque:

    vous pouvez utiliser l'un des scripts de contrôle d'accès fournis avec Subversion pour empêcher quiconque de faire quoi que ce soit, mais de créer de nouvelles copies dans la zone de balises.

Une étiquette est définitive. Son contenu ne devrait jamais changer. JAMAIS. Déjà. Vous avez oublié une ligne dans la note de mise à jour? Créer un nouveau tag Obsolète ou supprime l'ancien.

Maintenant, je lis beaucoup sur "la fusion de tel ou tel dans telle ou telle branche, puis finalement dans la branche du tronc". C'est ce qu'on appelle le flux de travail de fusion et il n'y a rien d'obligatoire ici . Ce n'est pas parce que vous avez une branche de tronc que vous devez fusionner quoi que ce soit.

Par convention, la branche tronc peut représenter l'état actuel de votre développement, mais c'est pour un projet séquentiel simple, c'est-à-dire un projet qui a:

  • pas de développement "en avance" (pour la préparation de la prochaine version suivante impliquant de tels changements qu'ils ne sont pas compatibles avec le développement "tronc" actuel)
  • pas de refactoring massif (pour tester un nouveau choix technique)
  • pas de maintenance à long terme d'une version précédente

Parce qu'avec un (ou tous) de ces scénarios, vous obtenez quatre «troncs», quatre «développements actuels», et tout ce que vous faites dans ces développements parallèles ne doit pas nécessairement être fusionné dans le «tronc».




Je ne suis pas vraiment sûr de ce qu'est le 'tag', mais branche est un concept de contrôle de source assez commun.

Fondamentalement, une branche est un moyen de travailler sur les modifications du code sans affecter le tronc. Supposons que vous souhaitiez ajouter une nouvelle fonctionnalité assez compliquée. Vous voulez pouvoir enregistrer les modifications au fur et à mesure que vous les créez, mais vous ne voulez pas qu'elles affectent le tronc tant que vous n'en avez pas fini avec la fonctionnalité.

D'abord, vous créez une branche. Il s'agit essentiellement d'une copie du coffre au moment de la création de la succursale. Vous feriez alors tout votre travail dans la branche. Les modifications effectuées dans la branche n'affectent pas le tronc, de sorte que le tronc est toujours utilisable, ce qui permet à d'autres de continuer à y travailler (comme faire des corrections de bogues ou de petites améliorations). Une fois votre fonctionnalité terminée, vous pouvez réintégrer la branche dans le coffre. Cela déplacerait tous vos changements de la branche au tronc.

Il y a un certain nombre de modèles que les gens utilisent pour les succursales. Si vous avez un produit avec plusieurs versions majeures supportées en même temps, habituellement chaque version serait une branche. Là où je travaille, nous avons une branche QA et une branche Production. Avant de livrer notre code à QA, nous intégrons les modifications à la branche QA, puis nous déployons à partir de là. Lors de la mise en production, nous intégrons la branche QA à la branche Production, nous savons donc que le code exécuté en production est identique à celui testé par QA.

Voici l'entrée Wikipedia sur les branches , car elles expliquent probablement les choses mieux que je ne peux. :)




Une des raisons pour lesquelles tout le monde a une définition légèrement différente est que Subversion implémente un support zéro pour les branches et les tags. Subversion dit essentiellement: Nous avons examiné les branches et les balises complètes dans d'autres systèmes et nous ne les avons pas trouvées utiles, donc nous n'avons rien implémenté. Faites simplement une copie dans un nouveau répertoire avec une convention de nom à la place . Alors bien sûr, tout le monde est libre d'avoir des conventions légèrement différentes. Pour comprendre la différence entre une balise réelle et une simple convention de copie + dénomination, consultez l'article Wikipédia Subversion tags & branches .




En ce qui concerne le développement de logiciels, il n'y a pas de connaissances cohérentes sur quoi que ce soit, tout le monde semble l'avoir à sa manière, mais c'est parce que c'est une discipline relativement jeune de toute façon.

Voici ma façon simple et simple

trunk - Le répertoire trunk contient le corpus de travail le plus récent, approuvé et fusionné. Contrairement à ce que beaucoup ont avoué, ma malle est uniquement pour un travail propre, soigné et approuvé, et non une zone de développement, mais plutôt une zone de dégagement.

À un moment donné, lorsque le tronc semble prêt à être libéré, il est étiqueté et libéré.

branches - Le répertoire des branches contient des expériences et des travaux en cours. Travailler sous une branche reste là jusqu'à ce qu'il soit approuvé pour être fusionné dans le coffre. Pour moi, c'est le domaine où tout le travail est fait.

Par exemple: Je peux avoir une branche itération-5 pour un cinquième cycle de développement sur le produit, peut-être une branche prototype-9 pour un neuvième cycle d'expérimentation, et ainsi de suite.

tags - Le répertoire des balises contient des instantanés de branches approuvées et de versions de jonctions. Chaque fois qu'une succursale est autorisée à fusionner dans le circuit ou qu'une version du réseau est validée, un instantané de la version approuvée de la succursale ou du circuit est effectué sous des balises.

Je suppose qu'avec des balises, je peux sauter dans le temps pour pointer l'intérêt assez facilement.




Tronc : Après l'achèvement de chaque sprint en agile, nous sortons avec un produit partiellement expédiable. Ces versions sont conservées dans le coffre.

Branches : Tous les codes de développements parallèles pour chaque sprint en cours sont conservés dans les branches.

Tags : Chaque fois que nous publions un produit en version bêta, nous faisons un tag pour cela. Cela nous donne le code qui était disponible à ce moment-là, ce qui nous permet de revenir à cet état si nécessaire à un moment donné au cours du développement.






Related