Je suis partant avec SVN. Je sais que les commandes de base et de comprendre les principes de base. Je me demandais si quelqu'un a des conseils ou de meilleures pratiques pour travailler avec Subversion dans un environnement d'équipe.
Je peux voir les avantages de l'ajout d'raisonnablement détaillé des messages lors de la validation de code, mais existe-il d'autres choses que je devrais garder à l'esprit?
Merci pour toutes ces excellentes réponses - ils ont aidé beaucoup.
Encourager les fréquentes révisions. Les coéquipiers de nouveau au contrôle de version peut ressentir le besoin de garder le code depuis le dépôt jusqu'à ce que "ça marche". Enseigner à tout le monde de commettre tôt et souvent pour détecter les problèmes dès que possible. Au lieu de la tenue de code jusqu'à ce qu'il fonctionne, proposer à vos coéquipiers de créer des branches pour la fonctionnalité qui pourrait casser le tronc. Qui mène à...
Établir un embranchement et de l'étiquetage de la pratique. En plus de branches pour les fonctionnalités, encourager vos coéquipiers à utiliser les branches pour les grands-corrections de bugs. Tag les correctifs les plus importants au début et à la fin de l'œuvre. Maintenir les balises (et éventuellement les branches) pour la production/qa versions.
Mettre en place une politique pour le tronc et s'en tenir à elle. Un exemple pourrait être, "le tronc doit toujours construire sans erreurs." ou "tronc doit toujours passer tous les tests unitaires". Tout travail ne peut pas encore répondre à des normes de tronc doit être fait dans une branche.
Ne pas commettre d'modifications de mise en forme avec les changements de code
Si vous souhaitez restructurer un géant du fichier d'espaces (Contrôle+K+D), de l'amende. Engager la modification de mise en forme séparément de la logique de changement. En va de même si vous souhaitez déplacer les fonctions de autour de dans fichiers. Engager le mouvement séparément de l'édition.
L'un des concepts clés j'ai toujours coller en est de commettre liées à des modifications de code ensemble. Le corollaire est de ne pas s'engager sans rapport avec les modifications de code dans la même livraison. Cela signifie ne pas fixer de 2 bugs dans un commit (sauf si c'est le même correctif), et de ne pas commettre d'un demi-correction d'un bug dans chacune des 2 s'engage. Aussi, si je dois ajouter quelques nouvelles d'amélioration ou de quelque chose à une autre partie du système que je puis avoir besoin pour un autre travail, je m'engage à l'amélioration séparément (et première). L'idée est que toute modification quelqu'un pourrait peut-être voulez avoir sur son propre (ou revenir sur ses propres) doit être séparé de la validation. Il vous permettra d'économiser des tonnes de maux de tête quand vient le temps de faire des fusions ou à revenir sur les brisées de fonctionnalités.
Beaucoup a été déjà mentionné, voici quelques-uns:
Si vous avez des fichiers que vous ne voulez pas de contrôle à la source (par exemple, la configuration, les fichiers compilés, etc), les ajouter à la liste des ignorés. De cette façon, vous remarquez des fichiers que vous avez oublié d'ajouter, toujours en s'attendant à une liste vide de fichiers indiquant que inconnu à SVN.
Ajouter un post-validation des événement qui allait envoyer un e-mail à votre dev liste de diffusion (ou de l'un spécifique pour cette cible) relatives à la volonté de changement et, idéalement, le patch pour elle.
L'intégration avec votre tracker de bug , de sorte que les références s'engage à se montrer sur les bugs / demandes de fonctionnalités avec des liens vers les diff. Bug trackers comme MantisBT l'appui de cette.
Envisager l'intégration avec d'intégration continue (par ex. CruiseControl.NET), NAnt pour la construction, et NUnit/VS pour les tests unitaires. De cette façon, une fois qu'un utilisateur check-ins code ou sur un intervalle programmé le code est compilé, les tests unitaires sont exécutés, et le développeur reçoit de la rétroaction du processus. Cela permettrait également d'alerter le reste de l'équipe si le référentiel est cassé (c'est à dire de ne pas construire).
Ainsi, les principes de base:
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
