Dois-je stocker le code généré dans le contrôle de la source

Question

Il s'agit d'un débat auquel je participe. J'aimerais obtenir d'autres opinions et points de vue.

Nous avons quelques classes qui sont générées lors de la construction pour gérer les opérations de la base de données (dans ce cas spécifique, avec SubSonic, mais je ne pense pas que ce soit très important pour la question). La génération est définie comme une étape de pré-construction dans Visual Studio. Ainsi, chaque fois qu'un développeur (ou le processus de construction officiel) lance une construction, ces classes sont générées, puis compilées dans le projet.

Certaines personnes affirment que le fait d'enregistrer ces classes dans le contrôle de la source pourrait entraîner une confusion, au cas où le code obtenu ne correspondrait pas à celui qui aurait été généré dans votre propre environnement.

J'aimerais avoir un moyen de retracer l'historique du code, même s'il est généralement traité comme une boîte noire.

Des arguments ou contre-arguments ?

---

MISE À JOUR : J'ai posé cette question car je croyais vraiment qu'il existait une réponse définitive. En regardant toutes les réponses, je peux dire avec un haut niveau de certitude, qu'il n'y a pas de réponse définitive. La décision doit être prise en fonction de plus d'un paramètre. La lecture des réponses ci-dessous pourrait fournir une très bonne ligne directrice quant aux types de questions que vous devriez vous poser lorsque vous devez prendre une décision sur ce sujet.

Je ne sélectionnerai pas de réponse acceptée à ce stade pour les raisons mentionnées ci-dessus.

Answer 1

L'enregistrer dans le contrôle de la source est plus de problèmes que cela n'en vaut la peine.

Vous devez faire un commit à chaque fois que vous faites une construction pour que cela ait une quelconque valeur.

En général, nous laissons le code généré (idl, trucs jaxb, etc.) en dehors du contrôle de source là où je travaille et cela n'a jamais posé de problème.

Answer 2

Chaque fois que je veux montrer les changements apportés à un arbre source sur mon dépôt personnel, tous les "fichiers générés" apparaissent comme ayant été modifiés et devant être complétés.

Je préférerais avoir une liste plus propre de modifications qui ne comprendrait que les mises à jour réelles qui ont été effectuées, et non les changements générés automatiquement.

Laissez-les de côté, et après la construction, ajoutez un 'ignore' sur chacun des fichiers générés.

Answer 3

Mettez-le dans le contrôle du code source. L'avantage d'avoir l'historique de tout ce que vous écrivez à la disposition des futurs développeurs l'emporte sur la douleur mineure d'une reconstruction occasionnelle après une synchronisation.

Answer 4

Voyez les choses sous cet angle : vérifiez-vous vos fichiers objets dans le contrôle de la source ? Les fichiers sources générés sont des artefacts de construction tout comme les fichiers objets, les bibliothèques et les exécutables. Ils doivent être traités de la même manière. La plupart des gens soutiendraient que vous ne devriez pas vérifier les fichiers objets et les exécutables générés dans le contrôle de source. Les mêmes arguments s'appliquent aux fichiers sources générés.

Si vous avez besoin de consulter la version historique d'un fichier généré, vous pouvez vous synchroniser avec la version historique de ses sources et le reconstruire.

Le contrôle des fichiers générés de toute sorte dans le contrôle de la source est analogue à la dénormalisation des bases de données. Il existe occasionnellement Il existe des raisons de le faire (généralement pour des raisons de performances), mais cela ne doit être fait qu'avec beaucoup de précautions car il devient beaucoup plus difficile de maintenir l'exactitude et la cohérence des données une fois qu'elles sont dénormalisées.

Answer 5

Je dirais que vous devriez éviter d'ajouter tout code généré (ou autres artefacts) au contrôle de la source. Si le code généré est le même pour l'entrée donnée, vous pouvez simplement vérifier les versions que vous voulez différencier et générer le code pour comparaison.