À la Société, je travaille pour que nous utilisions Subversion et TortoiseSVN pour gérer notre code source. Chaque projet est ramifié sur le coffre. Lorsque nous devons intégrer les différents projets pour une version, nous créons une branche de version contenant le code qui sera intégré, testé et déployé à la production. Généralement, nous n'avons qu'une seule branche de libération.
Récemment, cependant, certains des éléments de l'un des projets ont été retardés et devaient entrer dans la prochaine version. En conséquence, une personne a demandé qu'une deuxième succursale de version soit créée pour contenir les modifications retardées et les empêcher de se lancer dans la version actuelle.
Jusqu'à présent, cela nous a amené beaucoup de chagrin et de nombreux conflits d'arbres car certains éléments de la future branche de libération dépendent des éléments de la branche de la version actuelle. La seule façon de pouvoir résoudre ces problèmes était d'attendre que la libération actuelle ait été déployée, fusionne la branche de libération dans le coffre, fusionner le tronc dans la branche de version future, puis fusionnez les modifications de la branche de projet dans la branche de version future. .
À la suite de ce problème, nous avons dû recommander que nous ne devrions jamais avoir plus d'une succursale de libération, car elle provoque des problèmes de fusion.
Cependant, je me demande si c'est la bonne façon de partir. Est-ce que quelqu'un sait s'il est possible de gérer plusieurs branches de libération à Subversion? Sûrement il doit être possible de gérer des fonctionnalités qui se retardent sans compromettre sa capacité à faire de la fusion.
Est-ce que quelqu'un existe-t-il une expérience concernant le scénario que j'ai présenté que vous seriez prêt à partager? J'aimerais juste savoir comment je peux améliorer la manière dont les versions sont gérées sur mon lieu de travail, de sorte que cela ne se reproduise pas.
5 Réponses :
Ce n'est pas là où la tortue excelle. Pour faire des scénarios de fusion et de branche compliqués, vous avez besoin de quelque chose comme ClearCase Config Spec pour effectuer votre contrôle de version.
Si vous utilisez de la tortue, vous gardez le mieux le coffre comme cela, puis exécutez une intégration continue sur le coffre ou de créer des succursales pour chaque fonctionnalité, la fusionnant lorsque le développement de fonctionnalités est terminé. Si vous le faites, vous n'aurez que de code sur le tronc qui est testé. Ensuite, vous choisissez un point de sortie, faites votre intégration et ramenez les correctifs requis dans votre coffre, mais permettant également à vos équipes de poursuivre leur développement.
Je pense que vous voulez un suivi de fusion, soit via Svnmerge.py, ou à travers le suivi de la fusion intégré de Subversion 1.5. Cela vous permet de bloquer certaines modifications d'être fusionné dans une branche, qui pourrait ensuite être effectuée à toutes les modifications liées aux fonctionnalités que vous souhaitez uniquement intégrer dans la prochaine version.
Vous voudrez presque toujours que des changements sur la première branche retardée soient présents en seconde. Donc, une seconde branche de version devrait être faite à partir de la première branche de version et les changements de la première fois doivent être fusionnés périodiquement. Idéalement par les mêmes personnes qui les ont fait en premier lieu.
SPELLADDER (?) La ramification fonctionnera bien dans ce cas - juste abandonner le coffre et monter.
Pour être honnête, je ne suis pas tout à fait sûr de savoir comment votre système fonctionne de la description. Cependant, j'ai dû gérer des projets avec plusieurs versions en direct dans le passé. La façon dont nous avons fait c'était:
De cette façon, nous pourrions chercher des cerises que des fonctionnalités étaient dans quelle version. En utilisant le suivi de la fusion, il nous permet également de construire une page Web qui nous a montré graphiquement ce qui est allé où.
La chose cruciale consiste à avoir une branche entièrement intégrée que vous pouvez choisir de - ceci est ma définition du coffre.
Ce n'est pas un système parfait. Si vous avez sauté des versions, les dépendances ont fait des choses difficiles et nous avions vraiment besoin de la chose graphique pour nous montrer ce qui était là où, mais globalement semblait bien fonctionner.
Voir aussi ma réponse ici .
Ma compagnie a eu des problèmes similaires.
Nous avons eu un projet de retard dans une version - nous l'appellerons 2,0 - de plusieurs mois. Entre-temps, nous avons eu des problèmes de production sur la branche actuelle - appelons cela 1.5 - Cela garantissait plus de rejets. Nous ne pouvions pas utiliser de malle, car il avait les caractéristiques de l'embargo, nous avons donc commencé à ramener des succursales. Notre libération 1.6 ramifiée de 1,5, pas de coffre. Autre que la convention de dénomination, la version 1.6 n'est vraiment rien de plus que 1.5.1. Comme ce n'est pas SOP, nous avons été très prudents de documenter ce que nous faisons.
Et je n'attends pas avec impatience le point de fusion, où nous réunissons enfin la branche 1.6 et 2.0. Nous sommes incapables de fusionner des modifications sur 1,6 de retour sur le tronc ou 2.0, car cela fait simplement QA sur les problèmes de 2,0 pires. Nous exécutons Subversion 1.4.6, donc aucune aide du logiciel - ce sera toutes les fusion manuelles.
Qu'entendez-vous par «chaque projet est ramifié du coffre»? Voulez-vous dire que vous utilisez des branches de fonctionnalités?
@wcoenen je ne suis pas tout à fait sûr comment l'expliquer. Je vais mettre à jour ma question plus tard avec un diagramme de la façon dont nous faisons des choses dans l'espoir de rendre les choses plus claires. Malheureusement, le gars qui sait le plus de nos procédures de ramification est absent lundi.