L'utilisation du coffre / Branches et structure Tag entre plusieurs développeurs

Question

Je finissent par se confondre quand il s'agit de trunk / branches et les étiquettes. Voici ma requête:

Nous avons une équipe de développeurs travaillant sur un même projet. Les développeurs sont souvent divisés en groupes et ils travaillent sur différents modules sur le même projet.

À l'heure actuelle, nous avons un système simple de SVN (sans trunk / branches ou tags) où tout le monde travaille sur le même serveur local et engage les fichiers. Mais le problème commence quand, deux développeurs travaillent sur des modules futurs (qui ne sont pas censés aller vivre immédiatement). Dans cette situation, ils ne peuvent pas valider les données parce que s'ils le font, leur code de développement sera téléchargé sur le serveur en direct et il va finir par gâcher tout.

Alors, maintenant, je suis à la recherche d'une sorte de solution où, ces développeurs peuvent travailler séparément, mais sur le même code. Quelque chose comme ceci:

Développeur A travaille sur un nouveau module A Le développeur B travaille sur un nouveau module B Développeur C travaille sur Correction de bugs du module C (qui est déjà en direct, mais quelques bugs doit être corrigé)

Alors, développeur A aura sa propre copie sur cette machine et engager dans le référentiel de développeur A. (Direction Or)

La même logique vaut pour le développeur B mais développeur C travailleront sur une copie stable commune qui sera quelque part dans les balises et une fois que le travail est fait, il sera marqué et poussé vers le tronc pour le téléchargement sur le serveur en direct.

Une fois que développeur A est fait avec le travail, il poussera tous ses fichiers Trunk pour le téléchargement direct. (Cela devrait fusionner certains fichiers communs dans le coffre aussi). la logique même pour le développeur B.

Je ne suis pas sûr si SVN sera la bonne solution pour cela ou non. Je ne sais même pas s'il y a un moyen plus simple à mettre en œuvre ce que je veux.

Tout type de suggestions sont les bienvenues.

Merci TTR

Answer 1

mon avis est tout d'abord que si tous vos développeurs travaillent sur des morceaux du projet, vous pouvez faire disparaître les branches. Il peut prendre un peu d'organisation (par exemple, des commentaires appropriés journaux et versioning), mais qui peut être beaucoup moins de tracas que branches et la fusion.

Ok, mais si vous faites des branches de besoin, ils sont faciles. Il y a plusieurs approches à cet égard, mais fondamentalement impliquent toutes une version « maître » où le code final se termine. cela peut être le tronc, ou certaines personnes préfèrent faire des changements sur le tronc, puis fusionner le code pour les branches de libération. Le « tronc est maître » est le concept le plus facile à saisir si.

En svn, ce qui rend une branche est facile - la copie de votre problème pas cher, donc seulement remplir un répertoire avec les choses (je recommande la suppression d'une branche une fois que vous avez terminé avec elle). SVN vous donne un type particulier de branche pour ce type de travail trop - Direction générale de la réinsertion . Il est spécial pistes SVN ce qui lui arrive, son conçu que vous créez une branche du tronc, le travail sur elle, il mise à jour de temps en temps avec les changements qui ont été apportées au tronc, puis réintégrez votre travail sur cette branche dans le tronc dans un bang final. Ensuite, vous pouvez tout recommencer. Il semble que cela pourrait être ce que vous voulez - généralement bien, vous n'auriez pas une branche par développeur, vous auriez une branche pour chaque paquet de travail.

Le problème avec par-dev branches est que comme une branche vit plus longtemps et plus, les changements qu'ils font sera de plus en plus difficile de revenir de fusion. Cela est particulièrement vrai si les développeurs ne se confondent pas le travail de l'autre dev dans leurs branches régulièrement (comme ils ont l'habitude de le faire).

svn fait des copies bon marché, je recommanderais sans doute la ramification du tronc entier pour chaque développeur. Je trouve que il est plus facile de se rappeler que, au lieu de ramification des répertoires individuels, et vous serez toujours en mesure de modifier les fichiers partagés ou communs sans avoir à se soucier si les engageant casseront une autre branche. (Si tu branche / tronc / Modulea et de trouver plus tard, vous avez besoin de changer / tronc / include / common_file le fichier commun ne sera pas dans votre branche comme premier branchement d'un sous-ensemble. Il suffit donc de branche à la racine qui n » t vous coûte tout supplémentaire)

Answer 2

Dans votre question, vous venez d'exprimer la raison fondamentale derrière l'ensemble trunk / tags / modèle branches - il est pour gérer exactement cette situation, ce qui est une situation normale pour un magasin de développement pour entrer dans après un court moment <. / p>

Une chose au plan est votre migration à partir d'un modèle à un modèle sans tronc de tronc.

Vous dites que vous n'avez pas le tronc, les balises, les branches, etc. Je suppose que votre apparence modèle quelque chose comme ceci:

/
 filea.html
 fileb.html
 dira/
  filex

Un mot d'avertissement -. ne pas essayer de branche le répertoire racine sous lui-même

par exemple:

svn cp / /branchA

Il en résulterait un répertoire qui ressemble à:

/
 filea.html
 fileb.html
 dira/
  filex
 branchA/
  ...
 branchB/
  ...

Dégrafage ce qui est une partie de la branche de la racine et les sous-branches devient assez assez rapidement intraitable.

Gardez-le propre - déplacer tout le code dans le tronc d'abord. C'est le genre de saut structurel qui nécessitera tout le monde (et tous vos systèmes de déploiement) pour supprimer leurs espaces de travail et obtenir tout de propre:

svn cp / /trunk

maintenant vous pouvez faire vos branches:

svn cp /trunk /branches/branchA

En vous donnant une structure comme:

/
 trunk/
  filea.html
  fileb.html
  dira/
   filex
 branches/
  branchA/
   ...

Une fois que les branches ont été faites, les années dev peuvent les consulter et de travailler sur eux. Votre système de déploiement peut pointer vers le tronc / au lieu du dossier racine et déployer que.

Les développeurs travaillant sur des corrections de bogues peuvent checkout tronc. Quand ils engagent, le système de déploiement va déployer leurs changements comme ils le font maintenant.

Lorsque branchA est terminé, les développeurs peuvent intégrer les changements dans le tronc comme l'indique gbjbaanb.

Juste une tête rapide vers le haut, bonne chance avec elle.