Utilisation de Subversion avec le modèle promotionnel

Question

Actuellement, nous utilisons Subversion pour le contrôle des sources, mais tous les travaux de fusion pour nos versions se fait manuellement. Nous diffusons plusieurs fois par an, afin de créer une branche pour chaque version. Tous les travaux des branches antérieures doit en faire les derniers. Les travaux sur les branches ultérieures ne doivent pas en faire les précédentes (ce qui est dans nos contrats). Je crois que ceci est connu comme le modèle promotionnel.

Je pense que le schéma ci-dessous illustre le mieux notre flux de travail souhaité, avec des branches en cours de création à chaque fois que le travail commence sur une nouvelle version, et les changements découlant de branches antérieures à celles plus tard.

|
1
|
|\
| \ 
| 2 
3 | 
|\| 
4 |
| |\
5 | \
| 6 |
| | 7
|\|\|
| |\|
8 9 |\
| | | \
|\| | 10
x |\| |
  | |\|
  | | | 

a b c d

• Est-ce que ce modèle fonctionne en douceur avec Subversion, malgré l'absence d'un tronc significatif?
• Travaillerais de suivi de fusion automatisée pour les mises à jour des branches antérieures à celles plus tard?
• Serait-il autorisé à fermer / supprimer / ignorer une branche (dans cette branche de libération exemple « a ») sans réinsertion?
• Serait-il correct de créer les branches fonctionnelles hors de chaque branche de sortie, et fusionnerait le travail de suivi pour ces? (Ils suivraient la recommandation de créer / fusion / modèle réinsèrent.)

Modifier - ajouter plus d'informations

.

La raison pour laquelle le modèle de coffre traditionnel Instable pourrait ne pas convenir est illustré par le schéma ci-dessous. Caractéristiques de chaque version ne sont pas nécessairement terminée pour la libération (certains clients peuvent être lents à confirmer les exigences). Nous voulons propager les modifications de branches antérieures à celles plus tard le plus tôt possible.

    a
    |
    1
    |
   b|\ a
    | \ 
    |  2
    3  |
    |  |
    4  |
  b/|c |
  / 5  |
 |  |  6
 7  |  |
 b  c  a

Dans ce cas, nous voulons fonction 2 (complété dans la branche a) dans la branche b, mais comme cela est une fusion d'enfant à des parents, et donc pas pris en charge par Subversion, il devra être fait manuellement. De même, la fonction 6 devrait être fusionnés manuellement deux fois. Je prévois que ce soit un processus relativement lent sujette à l'erreur et par rapport à des fusions suivies automatiquement.

Answer 1

Si je comprends votre situation, il n'y a rien dans vos exigences qui font des choses aussi complexes que vous semblez les faire. Vous mettez également l'accent beaucoup trop sur le fond automatique par rapport à une fusion manuelle (plus tard). branches CVS aurait été une autre affaire, mais pas de la façon gère SVN « branches » (à savoir, il ne fonctionne pas).

Vous pourriez avoir une première ligne de développement (instable ou stable) et de créer des branches pour chaque client ou la libération (ou les deux). Comme caractéristiques sont validées, soit ils se fondre à la ligne principale si les branches ultérieures peuvent inclure ces changements ou vous fusionnez toujours unidirectionnellement d'une branche mère. Rien ne vous oblige à fermer la succursale et la fusion est pas moins automatisée que cela aurait été de soutenir votre premier diagramme (chaotique) étant donné que vous avez plusieurs lignes de développement simultanées.

L'exigence que vous fusionnez que l'avant semble que vous avez juste besoin de fusionner les révisions du sous-ensemble de la ligne principale, les révisions après une révision de branche donnée. Faire de cette façon rejoint votre vous permettra de fusionner les modifications de branches arbitraires à la ligne principale aussi souvent que vous le souhaitez (car ils sont confirmés avec vos clients) et peuvent être appliqués avec confiance qui obtiennent appliqués les changements ne validés. Vous pouvez configurer la fusion automatique pour suivre cette révision de copie (voir --stop-sur-copie et se fond à base de gamme,). branches de sortie prennent ensuite des ensembles de changements confirmés qui se sont produits de l'avant un point donné.

SVN ne « piste fusionne » pas plus qu'elle ne prend en charge les branches (ce qui ne constitue pas, ils ne sont que des copies légers). Vous dites (ou svnmerge dit qu'il) va fusionner et applique ces changements. Vous pouvez obtenir l'effet que vous êtes contractuellement tenu de soutenir, quel que soit.

Pour répondre à vos questions posées:

• Je ne pense pas que le modèle que vous proposez est très efficace. Au contraire, il a un potentiel accru pour le chaos de suivi des fonctionnalités que vous pouvez avoir à analyser les branches des changements et de fusionner en avant à plusieurs reprises. De plus, il sera sans doute confondre les développeurs familiers avec SVN et les structures organisationnelles SVN plus traditionnelles.

• Bien sûr. Cela devrait être assez indépendant de la structure que vous avez choisi aussi. Vous allez avoir besoin / voulez garder une trace de vos points de révision quel que soit (peut-être via des scripts simples au pire).

• Bien sûr. Les directions générales ont efficacement sans frais dans SVN sur le côté serveur. Le côté client a un coût si vous le faites de racines entières checkouts mais qui est généralement une chose stupide à faire indépendamment. De même, il n'y a pas de problème en ignorant / suppression d'une branche. Il est juste un autre changement de la hiérarchie mondiale de révision comme tout autre copier / supprimer / renommer / etc.

• Cela devrait fonctionner quelle que soit la structure organisationnelle « ramification » mis en place. On dirait peut-être il y a un peu d'incompréhension sur ce que signifie être une « branche » dans SVN. Vous devriez être en mesure de mettre en place ce que vous voulez et effectuer « manuel » se confond avec une relative facilité, indépendamment puis plus tard mis en place la fusion automatique après quelques mises à jour des clients afin que vous puissiez comprendre votre fusion étapes un peu mieux.

Vive!

Answer 2

Vous dites:

  

Tous les travaux de branches antérieures doivent   en faire les derniers. Les travaux sur la suite   branches ne doivent pas en faire plus tôt   ceux (ce qui est dans nos contrats)

Ici, si nous remplaçons les branches avec les versions (je doute que vos clients savent ou se soucient de « branches »), nous obtenons:

  

Tous les travaux de versions antérieures doivent   en faire les derniers. Les travaux sur la suite   les rejets ne doivent pas en faire plus tôt   ceux (ce qui est dans nos contrats)

Je ne vois rien dans cette exigence de proposer le schéma de branchement très complexe que vous proposez - vous pouvez le faire avec le style classique « tronc instable » du développement. Soit vous avez plus d'exigences que vous ne nous avez pas parlé, ou que vous êtes sur l'ingénierie.