Utilisez Subversion Sans Trunk

Question

Mon équipe a récemment décidé de ne pas utiliser la branche « tronc » qui est typique de la plupart des dispositions de dépôt subversion. Nous avons constaté que, à un moment donné il y avait toujours une branche qui a fonctionné dans le rôle traditionnel que le tronc détiendraient dans d'autres référentiels. Autrement dit, nous avons toujours une branche numéro le plus élevé qui représente la prochaine version que nous travaillons. Par conséquent, une fusion avec le tronc est tout simplement superflu, donc nous nous sommes débarrassés du tronc.

Est-ce que quelqu'un d'autre là-bas faire cela?

Si oui, avez-vous remarqué des avantages / inconvénients?

Même si votre équipe ne le fait pas, quelqu'un at-il des idées sur cette mise en page?

Answer 1

Vous parlez du Promotionnel - document de Perforce met en évidence les problèmes avec elle -. la communication des rôles changeants de lignes de code et le travail se déplaçant entre les branches

Une extension de mon point de vue des problèmes énumérés:

1) Modification de la politique de lignes de code-:

Chaque ligne de code a une politique, que ce soit écrit et formalisé, ou totalement implicite dans la tête d'un développeur. Il définit par exemple:

• qui est autorisé à engager dans le code ligne
• le nombre de tests est nécessaire (Par exemple, faire les tests unité doivent passer, tests de régression, test complet du système)
• combien de personnes ont à la révision du Code modifications
• quel genre de changements sont permis

Avec l'approche du tronc, les politiques restent fixes, donc plus faciles à écrire, ce qui les rend plus facile de communiquer (plus important dans une équipe plus grande).

par exemple. Tronc:

• tout développeur peut commettre
• tout changement
• les tests unitaires doivent passer
• revue de code après commit

branche Version:

• seul développeur de maintenance
• uniquement bug fix
• test unitaire + tests de régression
• Revue de code par 2 autres développeurs avant commit

branche Tag:

• n'engage après la création

autocommutateur privé du développeur:

• Seules les contrôles de développement dans
• Tout changement
• L'essai ne nécessaire avant la fusion de trunk
• Code de révision avant la fusion Trunk

Si vous avez le modèle de promotion, alors vous avez une politique alors que dans le développement principal, doivent alors dire à tous lorsque vous changez de politique lors de la préparation à la libération, puis une autre politique (pour la ligne de code) une fois que la ligne est libérée.

Le modèle de promotion est facile d'entrer dans, il correspondent directement le chemin de contrôle non source de travail. Mais ça fait mal une fois que vous commencez à obtenir de grandes équipes.

Si vous regardez le développement du noyau Linux vous pouvez voir la tension entre le modèle promotionnel et le modèle Tronc: l'arbre de Linus est promotionnel - il passe par des cycles entre la fenêtre de fusion, et la période rc / stabilisation. Mais Linux à côté et -MM ont vu le jour pour donner un plus tronc comme la ligne.

Distribué SCM / VCS sont quelque peu différentes de toute façon, les politiques ne doivent pas être distribués à tous les développeurs, car développer chacun a ses propres arbres, et tire des changements quand il veut.

projets open-source souffrent du problème qu'ils ne peuvent pas forcer les gens à faire le travail de tâcheron de stabilisation d'une libération, après la ramification du tronc. Par conséquent, le modèle de promotion est plus important comme moyen de forcer les efforts de stabilisation, plutôt que de travailler sur les fonctionnalités.

2) Déplacement travail:

Un développeur peut travailler sur une fonction lorsque la politique de la ligne, il travaille sur des modifications à des corrections de bugs seulement, il doit maintenant passer sa copie de travail à une autre ligne de code. Cela peut varier de facile à extrêmement difficile selon le système SCM utilisé. Ce problème ne se produit pas si le développeur travaille sur le tronc, comme leur travail va tronc toujours. Si le développeur est sur une branche privée ou d'une fonction, leurs travaux n'empiètent sur le tronc (et la sortie) du tout.

Si une fonctionnalité est déjà cochée, mais est en retard de la version il est actuellement, vous devez travailler sur la façon de le retirer. Ce problème encore existant avec le modèle de tronc, mais peut-être un peu plus facile à résoudre - les choses picorage du tronc pour la libération. C'est là les branches fonctionnelles aident -. Mais ils ont un coût d'intégration

Answer 2

Mon problème avec le papier Perforce est qu'il rabroue le modèle promotionnel sans mentionner le principal avantage, réduit les frais généraux fusion. En fait, le document indique à tort que la, une réclamation ridiculuous « modèle de ligne principale » impose « pas les frais administratifs supplémentaires ». Le « toujours fusionner avec le tronc » signifie modèle juste que - vous avez la tête de tout le monde d'avoir à fusionner. Ceci est en tête inutile si vous avez la situation suivante (que nous avons):

a) une petite équipe (5 à 7 développeurs) tous à portée de voix les uns des autres. la communication est un quand nous avons besoin de faire une branche non-question

et

b) une base de code où il n'y a jamais vraiment seulement deux branches principales - une branche de production et "la chose suivante dans le développement". Peut-être une fois dans une lune bleue, nous avons 3.

Je suppose que mon point est - c'est une chose de la situation. Dire le « modèle de promotion a des problèmes » est comme dire « ne jamais utiliser un OR / M ». Cela dépend de votre environnement.

Answer 3

Subversion permet aux deux approches. Le tronc est pas une nécessité, mais une convention. Si vous l'avez, certains outils de travail plus facilement (par exemple des outils de migration pour Git). Si vous ne l'avez pas, vous devez faire des choses manuellement, mais je ne peux pas penser à quelque chose que vous remarquerez au cours de votre travail quotidien.

Answer 4

J'ai récemment commencé à travailler sur un projet qui est sur un dépôt subversion. Celui qui a créé le référentiel n'a pas suivi aucune disposition particulière - ils ont tout simplement bourrés dans la racine du référentiel (pas / tronc, pas de branches /, et certainement pas de balises /). Je voulais créer une branche pour travailler et quelques balises pour d'autres choses, mais réalisé à quel point il est difficile de faire un dépôt subversion qui ne suit pas une bonne mise en page.

Answer 5

Nous - en quelque sorte. Nous n'utilisons un tronc, mais créer une nouvelle branche pour chaque version de nos projets. Cette branche « étiquette » est alors le tronc pour chaque version, et nous en fusionnant Backport bugfixes modifications sur les anciennes versions.

Il fonctionne bien pour nous, mais nous avons beaucoup de sous-projets dans notre projet.

Answer 6

IME, dans certains environnements, le tronc est un bon endroit pour échanger des corrections et modifications depuis / vers. C'est, tout le monde fusionne leurs corrections le tronc, et tout le monde se confond les corrections des autres de le tronc. Nous avons trouvé cela très utile dans un environnement où beaucoup de code a été partagé entre de nombreux projets indépendants et où tous ces projets ont contribué au code partagé.

environnement peut être différent, cependant.