En utilisant SVN seul ou en petits groupes de travail - approche flux de travail?

Question

J'ai passé quelques mois à travailler sur une application web et nous sommes venus près de stade de la production. Il est temps bientôt pour développer le groupe de développement avec 1-3 personnes sur ce projet.

J'ai l'expérience pas trop sur le travail avec SVN, mais il est évidemment le choix pour une grande partie des plus grandes entreprises là-bas, donc je devine que les avantages de SVN sans aucun doute outweights le temps passé lors de la validation / vérification ins / check out etc.

Le flux de travail semble devenir un peu plus compliqué avec SVN, et même si j'ai lu Contrôle de version avec Subversion par O'Reilly Media et je ne suis pas encore sûr si elle est surpuissant d'utiliser SVN pour les raisons en dehors de sauvegarde lors du développement de groupe de travail seul ou dans un petit (1-3 personnes)?

Comment faites-vous? Quel est votre flux de travail avec le contrôle de version tout en travaillant seul ou en petits groupes de travail?

Merci!

Answer 1

Comme tout SCM, il est certainement pour plus que la sauvegarde.

1. Vous pouvez marquer des versions particulières, de sorte que vous pouvez identifier un point sur l'ensemble de votre code qui fait un communiqué.
2. Vous pouvez gérer les branches pour les différentes versions simultanées par exemple si vous avez besoin de gérer des corrections de bugs pour une version tout en développant une nouvelle version de votre solution.
3. Vous pouvez gérer plusieurs développeurs et utiliser la capacité de fusion de SVN pour gérer les changements simultanés, de sorte que vos développeurs ne marchent pas sur les pieds et d'autres ou d'effacer les Ecraser changements de chacun.

Je ne développe pas de moi-même sans SCM, et encore moins avec d'autres développeurs. Il est un outil de base dans votre boîte à outils et obtenir une valeur au fait avec plus tôt que tard.

Quel est mon flux de travail? Cela dépend de l'équipe et le SCM utilisé.

1. Si les SCM supports bien (par exemple Git), je vais créer une branche par bug / fonctionnalité. SVN est pas si chaud à la ramification, donc cela peut ne pas appliquer.
2. Je vérifie dans / fusion régulièrement . Si vous ne le faites pas souvent, le code de base va diverger de votre base de code de travail, et une fusion ultérieure deviendra plus difficile. De plus, vous voulez que vos membres de l'équipe d'avoir une visibilité de ce que vous faites.
3. Mon processus d'intégration continue (par exemple j'utilise un moteur de construction continue, comme TeamCity / cruisecontrol / Hudosn) construira / test et marquer éventuellement un dégagement sur un cycle build / test réussi.
4. Je vais créer une branche pour une version finale, et exécute cette version de maintenance pour la suite.

Answer 2

Non, ce n'est pas exagéré. Le contrôle de version est vital pour la programmation, peu importe si elle est seule, dans une petite ou une grande équipe. Elle permet d'éliminer la peur de faire un changement « mauvais », comme vous pouvez toujours revenir à la révision précédente. Il se souvient pourquoi un changement a été fait avec COMMIT messages. Il sait ce qui a changé en même temps. Et bien d'autres

Answer 3

Il n'y a pas grand-chose à ajouter à la réponse de Brian. Comme alternative, vous pouvez jeter un oeil à des systèmes de contrôle de source distribués (DSCM) comme Mercurial, Git ou Bazaar. À mon humble avis, ils sont un match parfait pour les petits groupes de développeurs, très facile à installer, mais parviennent néanmoins à l'échelle de grands projets.

Un bon tutoriel d'introduction sur Mercurial, écrit par Joel Spolsky, se trouve à http://hginit.com/.

_{(source: hginit.com )}