SVN Flux de travail - poulet Avant l'œuf - Avant la fusion V1 avec V2, je besoin d'un code de V1 à V2 sur le travail

Question

Notre équipe distribuée (3 devs internes et externes 3+ devs) Utilisez SVN pour gérer notre base de code pour un site Web. Nous avons une branche pour chaque version mineure (4.1.0, 4.1.1, 4.1.2, etc ...). Nous avons un tronc que nous fusionnons dans chaque version quand nous faisons un communiqué et publions sur notre site.

Un exemple du problème que nous avons est donc: Une nouvelle fonctionnalité est ajoutée, permet de l'appeler « la capacité de créer un projet » 4.1.1. Une autre caractéristique qui dépend de celui 4.1.1 est prévue pour 4.1.2, intitulé « Possibilité d'ajouter des tâches à des projets ».

Alors, le lundi, nous disons 4.1.1 est « fermé » et doit être testé. Nos développeurs distants généralement commencer à travailler sur les caractéristiques / billets pour 4.1.2 à ce stade. Tout au long de la semaine, nous allons tester 4.1.1 et corriger les bogues et les retourner à 4.1.1 engager. Puis, le vendredi ou, nous allons marquer 4.1.1, fusionner avec le tronc, et enfin, fusionner avec 4.1.2. Mais, pour les 4-5 jours, nous testons, 4.1.2 n'a pas le code de 4.1.1 que certaines des nouvelles fonctionnalités pour 4.1.2 dépendent.

Ainsi, un dev qui ajoute la « capacité d'ajouter des tâches à des projets » fonction, ne pas la « capacité de créer un projet » fonction pour construire sur, et doit faire des copies de fichiers manigances pour être en mesure de garder travailler.

Qu'est-ce que pourrait / devrait-on faire pour lisser ce processus?

  

P.S. Toutes mes excuses si cette question a été posée -. I a fait recherche, mais n'a pas pu trouver ce que je cherche

Answer 1

La façon dont nous le faisons est que tous développement se produit dans le coffre. Vous ne commettez même le tronc et les corrections nécessaires pour 4.1.1 se fondre de trunk la branche 4.1.1. La branche 4.1.2 est créé uniquement lors de l'essai sur 4.1.2 commence - une fois que la branche 4.1.2 est fait, le travail se poursuit dans le coffre et si des correctifs sont nécessaires pour 4.1.2, ils sont faits dans le coffre, puis a fusionné en 4.1.2.

Il est très rare que nous faisons toujours un changement dans une branche qui doit fusionner retour dans le tronc (ou nulle part ailleurs, vraiment).

Answer 2

On dirait que vous avez besoin d'une branche X basée sur le tronc, et une branche Y basée sur X.

Vous pouvez développer une fonction X, et commencer à l'avoir testé. En attendant, vous copiez X à une nouvelle branche Y, et de développer la deuxième caractéristique là.

Finalement X se fusionne avec le tronc et libéré. Ensuite, lorsque vous travaillez fini sur Y, vous pouvez fusionner de nouveau dans X pour tester, puis dans le tronc pour la libération.

Vous pouvez répéter ce processus après que les deux fonctions sont libérées. La prochaine fois que vous terminez une fonction dans X, et vous voulez construire, juste fusionner de nouveau dans Y.

Si vous faites cela, il est important de se rappeler:

• Vous ne se confond normale du tronc dans X et de X dans Y.
• Vous ne se confond Réintégrer du dos X dans le tronc, et de Y revenir dans X.
• Après une fusion de se réinsérer dans le tronc, vous devez bloquer le commettras de l'être réincorporé dans X.
• Après une fusion dans X réinsèrent, vous devez bloquer le commettras de l'être réincorporé dans Y.
• Prenez des notes détaillées dont est fonction dans quelle branche; sinon cela peut se confondre rapidement.

Answer 3

j'aurais tous les nouveaux commits vont dans le coffre moins qu'il y ait une raison de les mettre ailleurs. En créant différentes branches pour 4.1.1 et 4.1.2, par exemple, votre exemple est mieux en se faisant entre les branches, se confond toutes deux pourraient alors être de nouveau fusionné avec le tronc. Beurk! C'est mergeinfo l'enfer, à mon avis.

Voici quelques conseils de base du livre de Subversion:

http://svnbook.red-bean.com /en/1.5/svn.branchmerge.commonpatterns.html

Answer 4

Je suppose qu'il ya plusieurs façons de le faire.

Mais je pratique que le tronc est toujours stable. Non inachevé - Code instable devrait aller dans le coffre. S'il y a une nouvelle fonctionnalité à ajouter et il prend des jours, peut-être des semaines, je crée une branche pour elle. Quand il est fait, et la branche semble stable et testé, il se fusionne à nouveau dans le coffre, et la branche est supprimée.

De cette façon, le tronc restera stable. Et le code expérimental est toujours la branche i.

Si je pour un changement mon esprit de raison et de sauter un demi-projet réalisé, je ne dois penser à le tronc. Supprimer simplement la branche ....

Answer 5

Une approche est à la branche 4.1.2 de 4.1.1 au lieu du tronc (et bien sûr 4.1.1 du tronc).

Vous pouvez alors facilement fusionner 4.1.1 en 4.1.2 régulièrement et toujours être en mesure de faire le dos de fusion trivial dans le tronc pour chaque branche quand il est temps de libération.