Trouver des bogues dans les copies de travail de révision mixte de Subversion

Question

Le projet sur lequel je travaille a récemment été remplacé par Subversion, un système de contrôle des versions horriblement archaïque. J'avais l'impression d'avoir une assez bonne compréhension de Subversion il y a quelques années, mais une fois que j'ai appris à connaître Mercurial, j'ai rapidement oublié Subversion.

Ma question s'adresse à ceux qui travaillent avec un nombre important de développeurs (15+) sur la même branche dans Subversion.

Supposons que vous récupériez rev N du référentiel. Vous faites quelques changements et ensuite commettez. Pendant ce temps, d'autres développeurs ont apporté des modifications à d'autres fichiers. Vous entendez parler d'un autre développeur modifie le sous-système X et décidez que vous en avez besoin immédiatement. Vous ne voulez pas mettre à jour l'ensemble de la copie de travail, car cela entraînerait toutes sortes de choses et vous devrez alors faire une longue compilation (projet C++). Le risque que je vois est que le développeur ne met à jour que le sous-système X sans se rendre compte que le nouveau code dépend d'un changement récent dans le sous-système Y. Le code compile, mais tombe en panne à l'exécution.

Comment gérez-vous cela? Le développeur signale-t-il ce qu'il pense être un bogue (même si ce n'est pas un bogue)?

• Avez-vous besoin de développeurs pour mettre à jour toute leur copie de travail avant de signaler un bug? Cela ne pourrait-il pas décourager les rapports de bugs?
• Empêchez-vous que cette situation se produise par un mécanisme auquel je n'ai pas pensé?

Answer 1

Depuis que vous avez engagé tout votre travail en cours, vous n'avez aucune raison de ne pas mettre à jour votre copie avec toute la dernière révision. Le long compilateur fait partie du prix d'un grand projet. Le temps de compilation est presque toujours inférieur au temps passé à essayer de déterminer si vous avez un bug, ou s'il y a une incompatibilité obscure parce que vous n'avez pas tout vérifié.

Ce projet avait distribué des compilations à tous les postes de travail du groupe. Puisque nous avions environ 15 ordinateurs pour la tâche, cela signifiait que ce qui serait normalement une construction d'environ 6 heures prenait environ 25 minutes.

Answer 2

La responsabilité de garder la trace des dépendances est le develloper qui l'introduit. Dans ce cas, develloper X doit s'assurer que la modification fonctionne avec la version actuelle des autres sous-systèmes. Ou au moins documenter les versions avec lesquelles il travaille.

Les moyens que j'ai vu aider les devellopers à faire face à cela sont.

1. Inclure la vérification des dépendances dans le système de construction. De nombreux projets Open Source le font dans un script .configure.
2. Configurez le système de contrôle de version pour gérer cela pour vous. Je ne sais pas faire ça dans la subversion.

Ceci n'est évidemment pas un remède pour de longues périodes de compilation, mais cela aide à éviter les reconstructions inutiles. Les graphiques à dépendance complexe sont également une indication de conception discutable. Il peut être utile de refactoriser le code pour réduire le couplage entre sous-systèmes.