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

106

C'est un débat auquel je participe. J'aimerais avoir plus d'opinions et de points de vue.

Nous avons des classes qui sont générées au moment de la construction pour gérer les opérations DB (dans ce cas précis, 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é-génération dans Visual Studio. Ainsi, chaque fois qu'un développeur (ou le processus de construction officiel) exécute une construction, ces classes sont générées, puis compilées dans le projet.

Maintenant, certaines personnes affirment que l'enregistrement de ces classes dans le contrôle de code source pourrait être source de confusion, au cas où le code que vous obtenez ne correspond pas à ce 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 des contre-arguments?


MISE À JOUR: J'ai posé cette question car je croyais vraiment qu'il y avait une réponse définitive. En regardant toutes les réponses, je pourrais dire avec un haut niveau de certitude, qu'il n'y a pas de telle réponse. 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 indication des types de questions que vous devriez vous poser lorsque vous devez vous prononcer sur cette question.

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

Ron Harlev
la source
1
Vous pourriez être intéressé par une question similaire: stackoverflow.com/questions/739391/…
mouviciel
Je voudrais dire que dans le cas de SubSonic, il pourrait être intéressant de garder le contrôle du code source afin de suivre facilement (certaines) modifications de la base de données, au cas où vous n'auriez pas d'autre moyen de retracer l'historique de votre base de données.
Earlz
1
Dans ma réflexion, le principal problème est que différents développeurs n'obtiennent pas le même résultat lors de la génération des classes. La configuration pour les générer doit être archivée et donner des versions cohérentes dans tous les environnements de développement.
nawroth
1
Je ne sais pas comment faire cela, mais je pense que cette question devrait être fermée maintenant car elle est trop ouverte à l'opinion et à la discussion sans être étroitement liée à des systèmes de contrôle de source spécifiques ou à des types spécifiques de fichiers générés.
Chris Halcrow
C'est une excellente question, mais elle est trop basée sur l'opinion pour SO, comme l'indiquent les multiples réponses contradictoires et le propre commentaire du PO à cet effet.
Flimzy

Réponses:

48

L'enregistrer dans le contrôle de code source est plus problématique qu'il n'en vaut la peine.

Vous devez faire un commit à chaque fois que vous faites une compilation pour qu'elle ait une valeur quelconque.

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

Glen
la source
43
Je ne suis pas d'accord avec "vous devez faire un commit à chaque fois que vous construisez". Cela ne devrait pas entraîner de validation supplémentaire car la seule chose qui devrait affecter la validation est une modification du code qui change donc la source générée. Donc, en fait, vous devez valider le code généré uniquement lorsque vous avez déjà validé la modification à la source du code généré.
JaredPar
5
D'accord avec JaredPar. De plus, votre générateur de code peut être un outil externe, et si vous le mettez à jour, le code généré peut changer et vous devrez donc peut-être valider les modifications. Mais dans ce cas, je voudrais vraiment voir les changements dans le contrôle de source de toute façon.
van
Différents outils peuvent générer des sources différentes (au moins, ils peuvent différer dans les commentaires ou le formatage du code). Par exemple, Idea ajoute un commentaire "généré par l'idée" alors qu'Eclipse ne le fait pas.
Petr Gladkikh
1
L'opinion est partagée, marquer celle-ci comme une réponse véhiculerait un message erroné.
Espresso
34

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 de la reconstruction occasionnelle après une synchronisation.

JaredPar
la source
18
Ce n'est pas un avantage - puisque le code qui l'a créé est archivé, vous avez déjà «tout ce que vous écrivez» disponible pour les futurs développeurs.
Shane C. Mason
13
@Shane, je ne suis pas du tout d'accord. Avoir le code qui l'a créé n'équivaut pas à avoir le code. Toute étape supplémentaire qui doit être incluse pour la génération est une gêne supplémentaire lors de la recherche d'un bogue. Il est beaucoup plus simple de parcourir l'historique du code que d'extraire N versions du fichier et de régénérer N versions du code généré.
JaredPar
10
Il est parfois avantageux d'avoir les fichiers générés dans le contrôle de code source. Par exemple, si vous mettez à niveau un composant, dans ce cas SubSonic, vous pouvez facilement détecter les changements dans la source générée. Cela pourrait être utile pour détecter les bogues et les problèmes. Je n'ajouterais pas tout le code généré au contrôle de code source. Parfois, c'est très utile. La plupart des systèmes de contrôle de source vous permettront de faire une différence pour voir si les fichiers ont vraiment changé, bien que ce soit peut-être plus un processus manuel si vous devez annuler manuellement les fichiers même si le seul changement est l'horodatage.
Ryan
18
Par cette logique, vous devez également archiver vos fichiers objets compilés, bibliothèques et exécutables.
Laurence Gonsalves
9
Quel type de générateur de code utilisez-vous là où «la langue d'origine n'a pas de sens»? En ce qui concerne le suivi des versions de vos outils que vous utilisez pour créer chaque version du code, vous devez déjà résoudre ce problème pour l'ensemble de votre chaîne d'outils. Après tout, comment comptez-vous rétroporter un bogue vers une ancienne version de votre produit, à moins de savoir quelle version du compilateur et de l'éditeur de liens vous utilisiez à l'époque? Un générateur de code n'est pas différent de votre compilateur C ++ / Java / C #. Le fait que vous puissiez lire sa sortie est sans importance: son entrée est la source.
Laurence Gonsalves
31

Chaque fois que je veux afficher les modifications apportées à une arborescence source sur mon propre dépôt personnel, tous les «fichiers générés» apparaîtront comme ayant changé et doivent être validés.

Je préférerais avoir une liste plus claire des modifications qui n'incluent que les mises à jour réelles qui ont été effectuées, et non les modifications générées automatiquement.

Laissez-les de côté, puis après une compilation, ajoutez un 'ignorer' sur chacun des fichiers générés.

Kieveli
la source
3
De plus, lors des mises à jour, vous pouvez obtenir des conflits étranges que le VCS considérera comme nécessitant une résolution, mais qui se résoudront d'eux-mêmes la prochaine fois que vous construisez. Sans parler de l'encombrement des journaux, que je considère encore pire que l'encombrement de votre arbre local.
rmeador
5
Là où je suis, ils n'apparaissent pas comme «ayant changé» à moins qu'ils n'aient vraiment changé. S'ils ont été régénérés mais ont toujours le même contenu, donc la seule chose différente est les dates de création / modification des fichiers, le système pense qu'ils n'ont pas changé et tout va bien.
Joel Coehoorn
+1 Je veux seulement être responsable du code que j'écris, pas du code généré par une boîte à outils qui peut avoir eu des problèmes à l'époque qui sont maintenant impossibles à dupliquer (mais quelqu'un pourrait passer beaucoup de temps à essayer.)
dkretz
4
J'ai vu des outils de génération automatique qui mettent à jour l'horodatage à chaque fois qu'ils s'exécutent. Je les maudis.
Kieveli
25

Regardez les choses de cette façon: archivez-vous vos fichiers objets dans le contrôle de code source? Les fichiers source générés sont des artefacts de construction, tout comme les fichiers objets, les bibliothèques et les exécutables. Ils devraient être traités de la même manière. La plupart diront que vous ne devriez pas vérifier les fichiers objets et exécutables générés dans le contrôle de code source. Les mêmes arguments s'appliquent à la source générée.

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

La vérification des fichiers générés de toute sorte dans le contrôle de code source est analogue à la dénormalisation de la base de données. Il y a parfois des raisons de le faire (généralement pour les performances), mais cela ne doit être fait qu'avec beaucoup de soin car il devient beaucoup plus difficile de maintenir l'exactitude et la cohérence une fois que les données sont dénormalisées.

Laurence Gonsalves
la source
20

Je dirais que vous devriez éviter d'ajouter du code généré (ou d'autres artefacts) au contrôle de code 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 souhaitez différencier et générer le code pour comparaison.

Caractéristique
la source
1
FYI, j'ai partagé un script pour faire cette comparaison ici: stackoverflow.com/a/16754923/105137
kostmo
17

J'appelle le principe DRY. Si vous avez déjà les "fichiers source" dans le référentiel qui sont utilisés pour générer ces fichiers de code au moment de la construction, il n'est pas nécessaire d'avoir le même code validé "deux fois".

De plus, vous pouvez éviter certains problèmes de cette façon si, par exemple, la génération de code s'arrête un jour.

John Smith
la source
15

Non, pour trois raisons.

  1. Le code source est tout ce qui est nécessaire et suffisant pour reproduire un instantané de votre application à un moment donné ou précédent dans le temps - ni plus ni moins. Une partie de ce que cela implique est que quelqu'un est responsable de tout ce qui est enregistré. En général, je suis heureux d'être responsable du code que j'écris, mais pas du code qui est généré à la suite de ce que j'écris.

  2. Je ne veux pas que quelqu'un soit tenté d'essayer de raccourcir une version à partir de sources primaires en utilisant un code intermédiaire qui peut ou non être actuel (et plus important encore dont je ne veux pas accepter la responsabilité.) Et ce n'est pas trop tentant pour certaines personnes de se laisser entraîner dans un processus dénué de sens sur le débogage des conflits dans le code intermédiaire basé sur des constructions partielles.

  3. Une fois qu'il est sous contrôle de code source, j'accepte la responsabilité d'un fichier. être là, b. il est courant, et c. il peut être intégré de manière fiable avec tout le reste. Cela inclut le supprimer lorsque je ne l'utilise plus. Moins cette responsabilité est importante, mieux c'est.

dkretz
la source
14

Je ne pense vraiment pas que vous devriez les enregistrer.

Il est certain que tout changement dans le code généré sera soit du bruit - des changements entre les environnements, soit des changements à la suite de quelque chose d'autre - par exemple un changement dans votre base de données. Si les scripts de création de votre base de données (ou toute autre dépendance) sont sous contrôle de code source, pourquoi avez-vous également besoin des scripts générés?

Thatismatt
la source
8

La règle générale est non , mais si la génération du code prend du temps (en raison de l'accès à la base de données, des services Web, etc.), vous voudrez peut-être enregistrer une version mise en cache dans le contrôle de source et épargner à tout le monde la douleur.

Vos outils doivent également en être conscients et gérer l'extraction à partir du contrôle de code source lorsque cela est nécessaire, trop d'outils décident de récupérer à partir du contrôle de code source sans aucune raison.
Un bon outil utilisera la version mise en cache sans la toucher (ni modifier les pas de temps sur le fichier).

Vous devez également mettre un gros avertissement dans le code généré pour que les gens ne modifient pas le fichier, un avertissement en haut ne suffit pas, vous devez le répéter toutes les douzaines de lignes.

Shay Erlichmen
la source
6

Nous ne stockons pas non plus le code DB généré: puisqu'il est généré, vous pouvez l'obtenir à volonté dans n'importe quelle version donnée à partir des fichiers source. Le stocker serait comme stocker le bytecode ou autre.

Maintenant, vous devez vous assurer que le générateur de code utilisé dans une version donnée est disponible! Les versions plus récentes peuvent générer du code différent ...

PhiLho
la source
5

Laisser de côté.

Si vous archivez des fichiers générés, vous faites quelque chose de mal. Quel est le problème peut différer, il se pourrait que votre processus de construction est inefficace, ou autre chose, mais je ne peux pas le voir jamais être une bonne idée. L'historique doit être associé aux fichiers source et non à ceux générés.

Cela crée juste un casse-tête pour les personnes qui finissent par essayer de résoudre les différences, trouvent les fichiers qui ne sont plus générés par la construction, puis les suppriment, etc.

Un monde de douleur attend ceux qui enregistrent les fichiers générés!

riches
la source
4

Il existe un cas particulier où vous souhaitez archiver vos fichiers générés: lorsque vous devrez peut-être construire sur des systèmes où les outils utilisés pour générer les autres fichiers ne sont pas disponibles. L'exemple classique de ceci, et avec lequel je travaille, est le code Lex et Yacc. Parce que nous développons un système d'exécution qui doit construire et fonctionner sur une grande variété de plates-formes et d'architectures, nous ne pouvons compter que sur les systèmes cibles pour avoir des compilateurs C et C ++, pas les outils nécessaires pour générer le code de lexing / d'analyse pour notre définition d'interface traducteur. Ainsi, lorsque nous changeons nos grammaires, nous archivons le code généré pour l'analyser.

Phil Miller
la source
2
Des commentaires similaires s'appliquent aux fichiers générés par autoconf / automake; la plupart des gens archivent leurs fichiers ./configure et Makefile.in, même s'ils sont générés - la plupart des utilisateurs (et de nombreux développeurs) n'auront pas besoin de les reconstruire, et en archivant ces fichiers, vous n'avez pas besoin d'installer les outils automatiques construire.
Stobor
1
Oui, nous stockons également notre script de configuration et nos dépendances Make générées dans le contrôle de version.
Phil Miller
4

arrivant un peu tard ... en tout cas ...

Souhaitez-vous mettre le fichier intermédiaire du compilateur dans le contrôle de version source? En cas de génération de code, par définition le code source est l'entrée du générateur tandis que le code généré peut être considéré comme des fichiers intermédiaires entre la source "réelle" et l'application construite.

Je dirais donc: ne mettez pas le code généré sous contrôle de version, mais le générateur et son entrée.

Concrètement, je travaille avec un générateur de code que j'ai écrit: je n'ai jamais eu à maintenir le code source généré sous contrôle de version. Je dirais même que puisque le générateur a atteint un certain niveau de maturité, je n'ai pas eu à observer le contenu du code généré bien que l'entrée (par exemple la description du modèle) ait changé.

dilig0
la source
3

Dans certains projets, j'ajoute du code généré au contrôle de code source, mais cela dépend vraiment. Ma ligne directrice de base est que si le code généré fait partie intégrante du compilateur, je ne l'ajouterai pas. Si le code généré provient d'un outil externe, tel que SubSonic dans ce cas, je l'ajouterais au contrôle de code source. Si vous mettez régulièrement à niveau le composant, je souhaite connaître les modifications apportées à la source générée en cas de bogue ou de problème.

En ce qui concerne le code généré devant être archivé, le pire des cas consiste à différencier manuellement les fichiers et à restaurer les fichiers si nécessaire. Si vous utilisez svn, vous pouvez ajouter un hook de pré-validation dans svn pour refuser une validation si le fichier n'a pas vraiment changé.

Ryan
la source
3

Le travail de gestion de la configuration (dont le contrôle de version n'est qu'une partie) est de pouvoir effectuer les opérations suivantes:

  • Sachez quels changements et corrections de bogues ont été apportés à chaque version livrée.
  • Être capable de reproduire exactement n'importe quelle version livrée, à partir du code source d'origine. Le code généré automatiquement ne compte pas comme "code source" quelle que soit la langue.

Le premier garantit que lorsque vous dites au client ou à l'utilisateur final "le bogue que vous avez signalé la semaine dernière est corrigé et la nouvelle fonctionnalité a été ajoutée", ils ne reviennent pas deux heures plus tard et disent "non, ce n'est pas le cas". Il s'assure également qu'ils ne disent pas "Pourquoi fait-il X? Nous n'avons jamais demandé X".

Le second signifie que lorsque le client ou l'utilisateur final signale un bogue dans une version que vous avez publiée il y a un an, vous pouvez revenir à cette version, reproduire le bogue, le corriger et prouver que c'était votre correctif a éliminé le bogue plutôt que une certaine perturbation du compilateur et d'autres correctifs.

Cela signifie que votre compilateur, vos bibliothèques, etc. doivent également faire partie de CM.

Alors maintenant, pour répondre à votre question: si vous pouvez faire tout ce qui précède, vous n'avez pas besoin d'enregistrer des représentations intermédiaires, car vous êtes assuré d'obtenir la même réponse de toute façon. Si vous ne pouvez pas faire tout ce qui précède, tous les paris sont ouverts car vous ne pouvez jamais garantir de faire la même chose deux fois et d'obtenir la même réponse. Vous pouvez donc également mettre tous vos fichiers .o sous contrôle de version.

Paul Johnson
la source
2

Cela dépend vraiment. Au final, le but est de pouvoir reproduire ce que vous aviez si besoin. Si vous êtes en mesure de régénérer vos binaires exactement, il n'est pas nécessaire de les stocker. mais vous devez vous rappeler que pour recréer votre contenu, vous aurez probablement besoin de la configuration exacte avec laquelle vous l'avez fait en premier lieu, et cela signifie non seulement votre code source, mais aussi votre environnement de construction, votre IDE, peut-être même d'autres bibliothèques , générateurs ou trucs, dans la configuration exacte (versions) que vous avez utilisée.

J'ai rencontré des problèmes dans les projets où nous avons mis à niveau notre environnement de construction vers des versions plus récentes ou même vers un autre fournisseur, où nous n'avons pas pu recréer les binaires exacts que nous avions auparavant. C'est une vraie douleur lorsque les binaires à développer dépendent d'une sorte de hachage, en particulier dans un environnement sécurisé, et que les fichiers recréés diffèrent d'une manière ou d'une autre en raison des mises à niveau du compilateur ou autre.

Alors, voudriez-vous stocker le code généré: je dirais non. Les binaires ou les livrables publiés, y compris les outils avec lesquels vous les avez reproduits, je les stockerais. Et puis, il n'est pas nécessaire de les stocker dans le contrôle de code source, faites simplement une bonne sauvegarde de ces fichiers.

nojevive
la source
"cela ne signifie pas seulement votre code source, mais aussi votre environnement de construction, votre IDE, peut-être même d'autres bibliothèques, générateurs ou trucs" \ n C'est tout ce que je vérifierais. Si vous construisez votre compilateur à partir des sources sur chaque machine de développement dans le cadre de la même version que vos applications (c'est-à-dire: vous tapez «make» une fois), vérifiez la source. Si vous ne le faites pas, vérifiez les binaires
KeyserSoze
2

La bonne réponse est "ça dépend". Cela dépend des besoins du client. Si vous pouvez restaurer le code vers une version particulière et résister à tout audit externe sans elle, vous n'êtes toujours pas sur des bases solides. En tant que développeurs, nous devons tenir compte non seulement du «bruit», de la douleur et de l'espace disque, mais aussi du fait que nous sommes chargés de générer la propriété intellectuelle et qu'il peut y avoir des ramifications juridiques. Seriez-vous en mesure de prouver à un juge que vous êtes en mesure de régénérer un site Web exactement comme un client l'a vu il y a deux ans?

Je ne vous suggère pas de sauvegarder ou de ne pas enregistrer les fichiers générés, quelle que soit la manière dont vous décidez si vous n'impliquez pas les experts en la matière de la décision que vous avez probablement tort.

Mes deux centimes.

James Fleming
la source
Vous faites un point intéressant, et ne prenez pas personnellement le vote négatif, c'est juste que pour des raisons pratiques dans des environnements de développement souvent rapides, ce n'est tout simplement pas pratique. Pourquoi, dans tous les cas, un code généré automatiquement contiendrait-il des données relatives au contenu ou à la propriété intellectuelle? Je suggérerais que les clients en général ne seraient pas en mesure de saisir les implications du code généré automatiquement de contrôle de source et qu'en général, cette option ne devrait probablement pas être proposée. IMHO c'est trop de frais généraux et de dépenses, pour s'occuper d'une situation juridique hypothétique et improbable.
Chris Halcrow
Dans le domaine dans lequel je suis actuellement, l'assurance de notre (très gros) client garde TOUT pendant au moins 10 ans. Nous créons des outils sophistiqués pour générer des services WCF. Les clients conservent le code généré, les modèles, le tout. Mais c'est mon client. Je suppose que vous avez manqué le point que je disais que "cela dépend des besoins du client" et "quelle que soit la façon dont vous décidez si vous n'impliquez pas les experts en la matière de la décision que vous avez probablement tort." Si d'une manière ou d'une autre c'est une mauvaise réponse, ou si vous vous sentez mieux en donnant un -1, heureux d'avoir aidé. Reportez-vous à «womp» sur le commentaire ci-dessus ma réponse.
James Fleming
2

Il y a de bons arguments pour et contre présentés ici. Pour mémoire, je construis le système de génération T4 dans Visual Studio et notre option par défaut prête à l'emploi provoque l'archivage du code généré. Vous devez travailler un peu plus si vous préférez ne pas vous enregistrer.

Pour moi, la considération clé est de faire varier la sortie générée lorsque l'entrée ou le générateur lui-même est mis à jour.

Si votre sortie n'est pas archivée, vous devez alors prendre une copie de tout le code généré avant de mettre à niveau un générateur ou de modifier une entrée afin de pouvoir comparer cela avec la sortie de la nouvelle version. Je pense que c'est un processus assez fastidieux, mais avec la sortie archivée, il suffit de comparer la nouvelle sortie au référentiel.

À ce stade, il est raisonnable de se demander "Pourquoi vous souciez-vous des changements dans le code généré?" (Surtout par rapport au code objet.) Je crois qu'il y a quelques raisons principales, qui se résument à l'état actuel de la technique plutôt qu'à un problème inhérent.

  1. Vous créez du code manuscrit qui s'intègre étroitement au code généré. Ce n'est pas le cas dans l'ensemble des fichiers obj de nos jours. Lorsque le code généré change, il est malheureusement assez fréquent que certains codes manuscrits doivent changer pour correspondre. Les gens n'observent souvent pas un degré élevé de compatibilité ascendante avec les points d'extensibilité dans le code généré.

  2. Le code généré change simplement son comportement. Vous ne toléreriez pas cela de la part d'un compilateur, mais pour être honnête, un générateur de code au niveau de l'application cible un domaine de problème différent avec une plus large gamme de solutions acceptables. Il est important de voir si les hypothèses que vous avez faites sur le comportement précédent sont maintenant rompues.

  3. Vous ne faites tout simplement pas confiance à 100% à la sortie de votre générateur d'une version à l'autre. Les outils générateurs ont beaucoup de valeur, même s'ils ne sont pas construits et maintenus avec la rigueur de votre fournisseur de compilateur. La version 1.0 a peut-être été parfaitement stable pour votre application, mais peut-être que la version 1.1 présente maintenant quelques problèmes pour votre cas d'utilisation. Sinon, vous modifiez les valeurs d'entrée et constatez que vous exercez une nouvelle partie du générateur que vous n'aviez pas utilisée auparavant - vous risquez d'être surpris par les résultats.

Essentiellement, tout cela dépend de la maturité des outils - la plupart des générateurs de code d'applications d'entreprise ne sont pas proches du niveau des compilateurs ou même des outils de niveau lex / yacc depuis des années.

GarethJ
la source
2

Les deux parties ont des arguments valables et raisonnables, et il est difficile de s'entendre sur quelque chose de commun. Les systèmes de contrôle de version (VCS) suivent les fichiers que les développeurs y ont placés et supposent que les fichiers à l'intérieur du VCS sont fabriqués à la main par les développeurs, et les développeurs sont intéressés par l'historique et le changement entre toute révision des fichiers. Cette hypothèse égalise les deux concepts, "Je veux obtenir ce fichier lorsque je passe à la caisse". et "Je suis intéressé par la modification de ce fichier."

Maintenant, les arguments des deux côtés pourraient être reformulés comme ceci:

  • "Je souhaite récupérer tous ces fichiers générés lors de l'extraction, car je n'ai pas l'outil pour les générer dans cette machine."
  • "Je ne devrais pas les mettre dans VCS, car je ne suis pas intéressé par la modification de ce fichier."

Heureusement, il semble que les deux exigences ne soient pas fondamentalement contradictoires. Avec une certaine extension des VCS actuels, il devrait être possible d'avoir les deux. En d'autres termes, c'est un faux dilemme. Si nous réfléchissons un peu, il n'est pas difficile de se rendre compte que le problème découle de l'hypothèse que les VCS tiennent. Les VCS doivent distinguer les fichiers, qui sont fabriqués à la main par les développeurs, des fichiers qui ne sont pas fabriqués à la main par les développeurs, mais qui se trouvent juste à l'intérieur de ce VCS. Pour la première catégorie de fichiers, que nous appelons généralement les fichiers source (code), les VCS ont fait un excellent travail maintenant. Pour cette dernière catégorie, les VCS n'ont pas encore eu un tel concept, pour autant que je sache.

Résumé

Je prendrai git comme exemple pour illustrer ce que je veux dire.

  • git status ne doit pas afficher les fichiers générés par défaut.
  • git commit doit inclure les fichiers générés en tant qu'instantané.
  • git diff ne doit pas afficher les fichiers générés par défaut.

PS

Les hooks Git pourraient être utilisés comme solution de contournement, mais ce serait génial si git le prend en charge nativement. gitignorene répond pas à nos exigences, car les fichiers ignorés n'iront pas dans les VCS.enter code here

Albert Netymk
la source
1

Je plaiderais pour. Si vous utilisez un processus d'intégration continue qui vérifie le code, modifie le numéro de version, construit le logiciel puis le teste, il est alors plus simple et plus facile de simplement avoir ce code dans votre référentiel.

De plus, cela fait partie intégrante de chaque «instantané» que vous prenez de votre référentiel logiciel. Si cela fait partie du logiciel, alors il devrait faire partie du référentiel.

womp
la source
5
J'adore le lecteur par -1. Si vous n'êtes pas d'accord, ne votez pas - votez pour les autres réponses. Enregistrez les votes négatifs pour une mauvaise réponse. C'est une question subjective.
womp
1

Je dirais que oui, vous voulez le mettre sous contrôle de source. Du point de vue de la gestion de la configuration, TOUT ce qui est utilisé pour produire une version logicielle doit être contrôlé afin de pouvoir être recréé. Je comprends que le code généré peut facilement être recréé, mais on peut faire valoir que ce n'est pas le même puisque la date / les horodatages seront différents entre les deux versions. Dans certains domaines comme le gouvernement, ils exigent souvent que ce soit ce qui est fait.

marque
la source
2
Archivez-vous vos fichiers objets (.o)?
KeyserSoze
1

En général, le code généré n'a pas besoin d'être stocké dans le contrôle de code source car l'historique des révisions de ce code peut être retracé par l'historique des révisions du code qui l'a généré!

Cependant, il semble que l'OP utilise le code généré comme couche d'accès aux données de l'application au lieu d'en écrire une manuellement. Dans ce cas, je modifierais le processus de construction et validerais le code dans le contrôle de code source car il s'agit d'un composant critique du code d'exécution. Cela supprime également la dépendance sur l'outil de génération de code du processus de construction au cas où les développeurs auraient besoin d'utiliser une version différente de l'outil pour différentes branches.

Il semble que le code ne doit être généré qu'une seule fois au lieu de chaque build. Lorsqu'un développeur doit ajouter / supprimer / modifier la façon dont un objet accède à la base de données, le code doit être généré à nouveau, tout comme pour des modifications manuelles. Cela accélère le processus de construction, permet d'effectuer des optimisations manuelles sur la couche d'accès aux données et l'historique de la couche d'accès aux données est conservé de manière simple.

Benson
la source
Je ne suis pas d'accord. Si vous en faites un processus manuel, il sera cassé et personne ne le remarquera jusqu'à ce qu'il soit temps de le réexécuter. S'il est généré tous les jours sur vos serveurs de build (et sur chaque machine de développement lorsque vous effectuez une build «propre»), vous ne serez pas surpris.
KeyserSoze
Si le code de la couche d'accès aux données est archivé dans le contrôle de source, il ne devrait y avoir aucune surprise car les utilisateurs seront obligés de mettre à jour le code. Si quelqu'un change la version de l'outil de génération de code sur la machine de construction et que les développeurs ont d'anciennes versions sur leur machine de développement (une branche de code différente, peut-être), alors il y aura des maux de tête. Je suggère qu'il supprime l'étape de génération de code du processus de construction, car ils ne sont pas les mainteneurs du générateur de code.
benson
1

Je finis (malheureusement) par mettre beaucoup de sources dérivées sous le contrôle de la source parce que je travaille à distance avec des personnes qui ne peuvent pas être dérangées pour mettre en place un environnement de construction approprié ou qui n'ont pas les compétences pour le configurer afin que le les sources dérivées sont construites exactement comme il faut. (Et en ce qui concerne les autotools de Gnu, je suis moi-même l'une de ces personnes! Je ne peux pas travailler avec trois systèmes différents, chacun fonctionnant avec une version différente des autotools - et uniquement cette version.)

Ce type de difficulté s'applique probablement plus aux projets à temps partiel, bénévoles et open-source qu'aux projets payants où la personne qui paie les factures peut insister sur un environnement de construction uniforme.

Lorsque vous faites cela, vous vous engagez essentiellement à créer les fichiers dérivés uniquement sur un site ou uniquement sur des sites correctement configurés. Vos Makefiles (ou autre) doivent être configurés pour remarquer où ils s'exécutent et doivent refuser de rediriger les sources à moins qu'ils ne sachent qu'ils fonctionnent sur un site de construction sûr.

Norman Ramsey
la source
1

S'il fait partie du code source, il doit être placé sous contrôle de code source indépendamment de qui ou de ce qui le génère. Vous voulez que votre contrôle de source reflète l'état actuel de votre système sans avoir à le régénérer.

mezoid
la source
"sans avoir à le régénérer." alors vous archivez les binaires compilés? Enregistrez-vous également une version de la plate-forme cible? Cette stratégie ne va pas bien. :(
dss539
1
Et cela me donne un vote négatif ?? Bien sûr, vous ne archivez pas les binaires compilés (sauf s'ils proviennent de bibliothèques tierces) car ils peuvent être régénérés à partir de votre code source. Je parlais de devoir régénérer le code généré et non les binaires. Mais bon, si vous voulez mal interpréter ce que je dis alors allez-y ...
mezoid
Cette réponse ne valait pas un vote négatif! À tout le moins, il semble judicieux de mettre du code généré dans SC (peut-être à un endroit clairement identifié) afin qu'au moins vous puissiez comparer le hachage du code utilisé pour générer l'objet avec le nouveau code que vous allez utiliser générer pour une nouvelle construction. Intéressant à quel point cette question est polarisante.
rp.
1

Ayez absolument le code généré dans le contrôle de code source, pour de nombreuses raisons. Je répète ce que beaucoup de gens ont déjà dit, mais certaines raisons pour lesquelles je le ferais sont

  1. Avec les fichiers de code dans le contrôle de code source, vous pourrez potentiellement compiler le code sans utiliser votre étape de pré-génération Visual Studio.
  2. Lorsque vous effectuez une comparaison complète entre deux versions, il serait bon de savoir si le code généré a changé entre ces deux balises, sans avoir à le vérifier manuellement.
  3. Si le générateur de code lui-même change, vous voudrez vous assurer que les modifications apportées au code généré changent de manière appropriée. c'est-à-dire si votre générateur change, mais que la sortie n'est pas censée changer, alors lorsque vous allez valider votre code, il n'y aura aucune différence entre ce qui a été précédemment généré et ce qui est dans le code généré maintenant.
Joe Enos
la source
1
Et votre générateur de code lui-même n'est pas en contrôle de code source parce que ...?
Jeffrey Hantin
@Jeffrey: Je n'ai jamais dit que le générateur de code n'était pas en contrôle de code source.
Joe Enos
Je sais, je taquine juste. :-) J'ai trouvé que beaucoup de générateurs de code basés sur CodeDom aiment produire leur sortie dans un ordre aléatoire, cependant, donc pour la répétabilité (et donc la capacité de dire facilement si le code généré change d'une exécution à l'autre). J'ai écrit une routine qui trie le contenu d'unCodeCompileUnit dans un ordre canonique.
Jeffrey Hantin
0

Je laisserais les fichiers générés hors d'une arborescence source, mais je les mettrais dans une arborescence de construction séparée.

par exemple, le flux de travail est

  1. archiver / sortir / modifier / fusionner la source normalement (sans aucun fichier généré)
  2. Aux occasions appropriées, extrayez l'arborescence des sources dans un arbre de construction propre
  3. Après une compilation, archivez tous les fichiers "importants" (fichiers sources "réels", exécutables + fichier source généré) qui doivent être présents à des fins d'audit / réglementaires. Cela vous donne un historique de tout le code généré approprié + exécutables + quoi que ce soit, à des incréments de temps liés aux versions / tests d'instantanés, etc. et découplés du développement quotidien.

Il y a probablement de bons moyens dans Subversion / Mercurial / Git / etc de lier l'historique des vrais fichiers source aux deux endroits.

Jason S
la source
0

On dirait qu'il y a des opinions très fortes et convaincantes des deux côtés. Je recommanderais de lire toutes les réponses les plus votées, puis de décider quels arguments s'appliquent à votre cas spécifique.

MISE À JOUR: J'ai posé cette question car je croyais vraiment qu'il y avait une réponse définitive. En regardant toutes les réponses, je pourrais dire avec un haut niveau de certitude, qu'il n'y a pas de telle réponse. La décision doit être prise en fonction de plus d'un paramètre. La lecture des autres réponses pourrait fournir une très bonne indication des types de questions que vous devriez vous poser lorsque vous devez vous prononcer sur cette question.

Ron Harlev
la source