comment gérer le code source en utilisant SVN? ramification, fusion

Question

Nous sommes une équipe de 4 développeurs/amis situés dans des endroits différents. Nous avons tous commencé à travailler sur l'un ProjectX et créé des branches A, B, C et D en utilisant Subversion.

nous avons juste des connaissances de base de la version contrôlant le code source. Autre jour l'un d'entre nous a juste essayé de fusionner la branche A avec B, C, et D et B ont essayé de fusionner avec A, C et D. (et ils ne savaient même pas comment le fusionner: D, juste clic droit> fusionner> fusionner une gamme de révisions) Nous avons eu quelques conflits, les avons résolus. Essayé de fusionner à nouveau, encore une fois clic droit .....) Conflits à nouveau.

Maintenant que tout le code a été foiré. nous avons 4 copies de code différentes (D manquant la fonctionnalité de B mais ayant des C etc etc). J'ai donc passé par beaucoup de discussions ici sur SO, lire le livre SVN et surtout this article (how to branch properly) m'a beaucoup aidé à comprendre comment fusionner les branches et le tronc. Je pense que j'ai une meilleure compréhension pour l'avenir. Mais comment sortir de la situation actuelle?

Mes questions sont les suivantes:

• Comme 4 d'entre nous travaillent sur un même projet, mais travaillent habituellement sur différents bits, devrions-nous juste une branche ?? puis créez 4 copies de travail, puis validez et mettez à jour uniquement. Une fois que nous sommes prêts fusionner le tronc à la branche, la branche au tronc? selon suggestion dans le above article
• Pouvez-vous s'il vous plaît suggérer un flux de travail afin que nous puissions obtenir nos 4 branches dans le coffre et puis je peux prendre une exportation pour recommencer le contrôle de version à partir de zéro.
• Aussi, je pense que si nous allons à nouveau avec 4 branches, devrions-nous tous les jours/régulièrement mettre à jour notre branche et obtenir des modifications de tronc (fusionner) et fusionner les modifications locales en tronc? (au lieu d'essayer mergin branche à branche: -D)

S'il vous plaît suggérer quel flux de travail nous devrions utiliser? de sorte que c'est un minimum de douleur dans le maintien du code. Merci.

Answer 1

Je ne créerais pas de branche par développeur. Je recommande un processus continuous integration où tous les quatre d'entre vous sortent d'un seul "tronc" et fusionnent les changements fréquemment - plusieurs fois par jour. Idéalement, vous auriez un outil de construction normalisé (par exemple Maven, Ant, etc.) et un planificateur de construction (par exemple Hudson, Cruise, TeamCity, etc.). En ayant ces deux outils au-dessus de votre outil SCM (Subversion), vous pouvez avoir un processus continuellement construit toutes les modifications que vous vérifiez dans le tronc et envoyer un email à tous les développeurs quand il y a un problème. Cela vous empêche de casser la construction par de mauvais changements ou des fusions tout en vous permettant de conserver une structure de dérivation légère (c'est-à-dire une branche - le tronc).

Les branches rendent plus difficile l'intégration de vos changements de code avec ceux de vos coéquipiers. Les branches devraient vraiment être utilisées pour, eh bien, branchement - créer des "branches" spécialement gérées de votre logiciel. Par exemple, si vous publiez la version 1.0 de votre logiciel, il serait probablement judicieux de créer une branche 1.0 du tronc (après le développement, mais avant de le relâcher) afin d'avoir une place pour maintenir cette version sans impact sur le fonctionnement développement sur le tronc (peut-être pour la version 2.0). Je recommande d'attraper Pragmatic Version Control with Subversion. C'est un aperçu assez solide de SCM avec des spécificités pour Subversion.

Answer 2

1. Vous devez utiliser une branche pour le développement principal. Ce n'est pas réellement une branche et s'appelle "tronc". Chaque développeur doit valider les modifications apportées au tronc. Vous devrez peut-être créer une branche lorsque vous publiez un code ou un changement majeur dans le programme. Ensuite, si vous apportez des modifications à la branche (disons patch pour la version précédente) et que vous souhaitez également avoir ces modifications dans le tronc principal, vous devez fusionner la branche vers le tronc.
2. Je ne connais pas de meilleur moyen que de passer en revue vos modifications et de fusionner manuellement dans un arbre de code.
3. Vous ne devriez pas aller avec 4 branches dans votre cas. Ce n'est pas la bonne façon d'utiliser le système de contrôle de version.

Answer 3

Généralement, si vous travaillez tous sur différentes parties du logiciel, vous trouverez qu'il est plus facile de travailler sur la même branche. Si vous ne travaillez pas couramment sur les mêmes fichiers source ou sur des parties du logiciel qui dépendent l'une de l'autre, vous ne trouverez pas fréquemment de conflits lorsque vous mettez à jour vos copies de travail ou une arborescence source endommagée lorsque vous validez.

Les branches dans SVN (par opposition à un système de contrôle de révision réparti) sont plus destinées à des changements importants susceptibles d'enfreindre le code de vos collègues ou d'exiger beaucoup de travail (auquel cas vous voulez faire beaucoup les validations incrémentales qui ne peuvent pas être compilées) ou des choses comme la gestion des versions.

Aller avec une seule branche (le tronc, comme indiqué dans d'autres réponses).Lorsque plusieurs personnes doivent travailler sur le même code, alors celui qui s'enregistre en seconde règle les conflits à la main. La résolution des conflits dans une révision est beaucoup plus facile que d'essayer de fusionner plusieurs révisions de changements dans une autre branche qui a également avancé plusieurs révisions depuis leur division.

Answer 4

Normalement, avec seulement 4 gars travaillant sur le code, vous n'avez pas besoin de 4 branches. Vous n'avez probablement pas besoin de branches du tout, mettez tout simplement dans un coffre et travaillez dessus. Pensez à votre copie de travail locale extraite comme votre "succursale locale anonyme".

Les branches sont utiles si vous prévoyez que votre code existe dans au moins deux versions pendant un certain temps. Par exemple, lorsque vous publiez la version 2.0 et que vous souhaitez commencer à travailler sur 2.1, vous devez prendre en charge la version 2.0 dans un avenir prévisible. Vous pourriez commencer 2.1 en tant que nouveau projet, mais vous perdriez alors la possibilité de porter des correctifs de 2.0 à 2.1 et vice versa. Donc vous nommez un tronc de version et une branche de celui-ci. Un autre scénario est lorsque l'un d'entre vous commence à implémenter un nouveau module ou à réimplémenter un module existant, et sait que cela prendra du temps (plus long que votre cycle de validation habituel) et ne peut pas garantir que cela n'affectera pas le code des gens pendant ce temps. Ensuite, vous le laissez brancher, développer son truc, et ensuite vous comprendre comment le fusionner. Ici encore, vous avez un tronc à partir duquel vous vous ramenez et vous revenez à.

Answer 5

Si vous êtes limité à SVN, continuez à lire, sinon, vous ressemblez à un candidat principal pour DVCS comme Mercurial, Git ou Bazaar.

Pour SVN, d'après mon expérience passée, il est généralement préférable de conserver le coffre où tout est fusionné (voir les exemples here). Chaque personne devrait fusionner de nouveau dans le tronc et ensuite vous fusionnez du tronc à votre branche. Fusionner de branche en branche dans SVN semble être une mauvaise idée.

Answer 6

Et une autre excuse pour poster un lien vers source control howto d'Eric Sink. C'est de loin la meilleure introduction au contrôle de la source que j'ai trouvée et qui est pertinente quel que soit les outils que vous utilisez.

Answer 7

La stratégie la plus sûre consiste à créer une branche pour chaque CR (Demande de changement/Tâche/Bug/etc). Le débit serait comme suit:

1. A CR est donnée à un développeur par l'intermédiaire d'un CMT (Change outil de gestion, comme Bugzilla);

2. Le CR est analysé. Si cela fait, il est accepté et le développeur crée une branche pour cela. Le nom de la branche pourrait être quelque chose comme:

   projectName_crNumber_crCreationDate_developerId

3. Une fois le travail effectué (testé, engagé, etc.), le développeur doit verrouiller la branche, alors personne ne le changer, marquer le CR comme résolu (indiquez le nom de la branche sur CR), et attendez que le CM (Configuration Manager) le fusionne avec une branche de construction (avec les autres branches de développement); Après la fusion d'un certain nombre de CR dans une branche de construction (build_xxx), cette version intégrée doit être testée. Si tout va bien, il devrait alors être fusionné au camion.

4. Une étiquette peut être appliquée chaque fois que le joncteur atteint un certain objectif/jalon (ensemble de CR).

Beaucoup de détails ont été omis. C'est un flux de travail adopté par de grandes équipes avec des standards de qualité élevés. Ce n'est peut-être pas assez flexible pour les petits groupes. Cependant, la plupart de ces tâches peuvent être automatisées et planifiées avec des outils existants.