Bonnes pratiques SVN Petit guide maison des bonnes pratiques Subversion

, par Julien Falconnet

Après quelques mois d’utilisation de SVN sur divers projets, dans différentes situations : seul, à plusieurs, en pilotage, etc. j’ai fini par me faire une liste de petites recettes pour que cela marche mieux.

Quand utiliser SVN ?

 au delà d’un jour de travail prévu.
 Dès qu’on atteint trois jours de dépassement

Quand utiliser Track/Redmine

 au delà d’une semaine de travail
 dès qu’on est deux à travailler dessus et qu’une analyse est nécessaire
 dès qu’une recette est prévue.

Comment soumettre (ou ’commiter’ en bon franglais)

 dès que le code est stable.
 dès que l’on peut dire "J’ai fait ça !"

Plus précisément, dans la plupart des cas, pour une nouvelle fonctionnalité, il faudra soumettre :
 Quand on a créé la(les) fonction(s) vide(s) (de préférence commentée). En effet en créant les fonctions vides d’abord, on limite les risques que les modifications touchent celles des autres, et donc qu’il y aie conflit.
 Dès qu’on a finit une fonction. En commençant par les fonctions de bibliothèque. En effet les fonctions de bibliothèques doivent être développées avant d’être intégrées, de sorte à ce que l’intégration ne provoque pas d’erreur en attendant d’être développées.
 Quand l’intégration sera finie. Il est important de soumettre l’intégration en toute indépendance pour permettre d’annuler cette intégration en une seule annulation de commit. Si on mélange intégration et débogage on risque de perdre le débogage en annulant l’intégration.

Pour un débogage
 une soumission par bug, sauf si le bug est complexe, c’est à dire composé de plusieurs bugs, alors on fera une soumission par sous-bug.

Pour une amélioration
 soumettre à chaque fois que l’amélioration est stable.

...