Ceci est un ensemble de bonne pratique à suivre lorsque l’on utilise subversion. Ces recommandations sont issues de mon expérience dans l’utilisation de subversion dans des projets aussi bien de petite que de grande taille.

#Testez avant de commiter Règle élémentaire tester que le code marche avant de faire un commit pour éviter de créer des problèmes aux autres développeurs. Si vous avez des tests unitaire vérifiez qu’il passe toujours. Ne commitez jamais un code qui ne marche pas et qui pourrait gêner un autre développeur.

#Faite un update avant de faire un commit Cela peut sembler aller de soi, mais certains développeurs ne le font pas. Ce n’est pas parce que subversion n’a pas râler à propose d’un conflit lors du commit que le projet marche toujours. En effet quelqu’un peut avoir changé le comportement de portion de code que vous utilisez.

#Pas de message de commit vide S’il y a une bonne pratique à imposer c’est celle là. Ecrire un message de commit qui décrit les changements prend 30 secondes, retrouver une version peut prendre des heures.

De plus avec de bons messages de commit vous pourrez mettre en place des notifications par mail ou des flux RSS.

Vous pouvez mettre un hook de pre-commit pour contrôler cela et refuser le commit lorsque le message est trop court.

#Synchronisez votre branche régulièrement Lorsque vous travaillez sur une branche vous ne devez pas rester pas trop longtemps désynchronisé du projet. Il vaut mieux traiter régulièrement des petits problèmes de merge qu’un gros merge qui a toutes les chances d’échouer et d’introduire des bugs.

J’ai connu une situation où un développeur a travaillé un mois sur sa branche et le travail accumulé pour le merge et le debuggage de ce merge fut tellement gros qu’il fallut mettre plusieurs personnes pour l’aider. Les changements étaient tellement importants qu’il était dur de localiser où les bugs avaient été introduit.

#Faite des commit atomique Lorsque vous faites un commit, commitez d’un bloc tous les changements (idéalement faite un commit à la racine du projet). Cela simplifie les retours en arrière et évite de polluer les logs.

#Mettez à jour tout le projet Faire un update sur seulement un fichier ou un répertoire c’est pratique, mais il ne faut pas en abuser. Beaucoup de problème mystique du type samarchechezmoietpascheztoi vienne d’update partiel. Et lorsque vous aurez passé une heure avec un de vos collègue à chercher un bug dû à cela vous ferez tout petit.

#Des normes de codes strict Par exemple faite votre choix pour des espaces ou des tabulations pour le projet, mais ne mélangeais pas les deux. Sinon à chaque modification votre éditeur de texte va tout réindenter et tout le fichier apparaîtra comme modifier lors des diffs.

#Commitez souvent A chaque fois que vous réalisez un pas dans le projet et que vous pouvez commiter sans gèner les autres faite le. En effet on ne sait jamais ce qui peut arriver le disque dur qui crash, maladie… En mettant vos sources sur le serveur subversion vous ou vos collègue pourrez toujours les récupérer.

C’est un avantage pour vous, car vous pouvez casser complétement votre code en ayant la garantie de pouvoir facilement revenir en arrière.