Utilisation SVN correcte des branches et du tronc

Question

J'ai une question quant à la bonne utilisation du tronc et des branches pour mes projets SVN. Pour le projet de mon équipe, nous créons 3 versions majeures chaque année et parfois une version mineure ou deux entre les deux. À tout moment, nous pouvons avoir un développement actif sur 2 ou même 3 versions. Nous faisons tout développement dans les branches avec une structure comme:

/branches/project1/2009.01
/branches/project1/2009.06
/branches/project1/2009.09
/branches/project1/2009.10

À ce jour, à chaque fois que je me prépare à créer une branche pour la prochaine version, j'ai fusionné les changements de la branche courante au tronc, puis je crée la nouvelle branche à partir du tronc. Je maintiens alors manuellement les dernières branches de dev à jour avec des corrections de bogues aux branches de version précédentes par des fusions à travers le tronc. Aucun développement ou commits ne sont jamais effectués sur le tronc (à l'exception du commit pour les fusions). Maintenant, je me demande ce que j'ai besoin du coffre. Quel serait le problème avec la création de la prochaine branche de publication directement à partir de la branche de publication précédente et de fusionner les mises à jour de correction de bogues directement d'une branche à l'autre. Pourrais-je simplement supprimer le projet sous le coffre? Tous les documents SVN sur les meilleures pratiques semblent indiquer que vous utilisez le tronc pour le développement, mais l'utilisation de branches séparées pour chaque version me semble beaucoup plus simple puisque nous pouvons travailler sur 2 ou 3 versions en même temps. Y at-il un problème technique avec mon utilisation SVN? Suggestions?

Merci!

Answer 1

Je ne pense pas qu'il y ait des problèmes avec la façon dont vous travaillez. Si cela fonctionne pour vous et votre équipe, c'est génial. Un avantage de garder le coffre est que toutes vos branches sortent du coffre, au lieu de se retrouver dans une situation plus désordonnée où chaque nouvelle branche de produits suspend la branche de produit précédente. Si vous deviez dessiner le graphique de révision, vous verriez qu'il deviendrait complexe très rapidement.

Answer 2

Je suis d'accord avec the_mandriill - il n'y a rien de mal à ce que vous faites, mais il n'y a rien de mal (OMI au moins) de remettre en question toujours si vous pouvez faire mieux.

Il y a un grand article un cmcrossroads qui vous donnera plus assez d'idées sur les différentes façons de gérer votre code.

K

Answer 3

Votre façon de travailler est bonne. Pour l'instant, tout se passe dans le coffre, vous avez donc un point de référence unique pour savoir où tout se trouve. Le problème de ne pas utiliser un tronc est d'avoir une connaissance solide de l'endroit où un bogue a disparu. Avec un coffre, le problème est linéaire. Sans tronc, il devient exponentiel, car vous devez comparer chaque branche à chaque autre branche pour voir ce qu'il y a dedans.

Personnellement, je préfèrerais ne voir aucun code provenir des branches de publication - faites d'abord des correctifs dans les branches dev, puis fusionnez-les via le tronc vers la branche de publication. Parfois, ce n'est pas pratique, mais l'histoire de fusion peut toujours être manipulée pour faire croire que c'est ce qui s'est passé. En général, un solide flux de code provenant des branches dev, du tronc et des versions est tout à fait compréhensible.

La raison est que vous pouvez attribuer un numéro de révision du coffre à chaque solution, et tracer cette révision en examinant simplement l'histoire de fusion de chaque version contre le tronc. Vous pouvez même tabuler cela pour voir exactement quelles corrections ont été publiées. (Par exemple, voir ma réponse here).

Si un correctif peut provenir d'une branche de publication, ce type de comparaison devient beaucoup plus difficile. Encore possible bien que je suppose. Mais s'il n'y a pas de tronc, vous devez comparer chaque release les uns contre les autres et cela devient une proposition beaucoup plus difficile.