MonoDevelop en crée pour chaque projet. Dois-je les inclure dans le contrôle de la source ?
Réponses
Trop de publicités?D'un Article de blog sur MonoDevelop :
Il y a eu plusieurs cas de longue attente rapports de bugs, et je voulais aussi améliorer un peu les performances et l'utilisation de la mémoire. MonoDevelop crée une base de données d'informations de l'analyseur (pidb) pour chaque assemblage ou projet. Ce fichier contient toutes les informations sur les classes implémentées dans un assemblage, ainsi que la documentation tirée de Monodoc. Un fichier pidb comporte trois sections : la première est une section en-tête qui contient entre autres choses la version du format de fichier (cette version est vérifiée lors du chargement le chargement du pidb, et le fichier sera régénéré s'il ne correspond pas à l'implémentation version actuelle de l'implémentation). Le site deuxième section est l'index du fichier pidb. Elle contient un index de tous les fichiers classes dans la base de données. L'index est toujours entièrement chargé en mémoire pour pouvoir pour pouvoir localiser rapidement les classes. Le site troisième section du fichier contient toutes les informations sur la classe : liste des méthodes, champs, propriétés, la documentation pour chacun d'entre eux, et et ainsi de suite. Chaque entrée de l'index possède un champ champ de décalage de fichier, qui peut être utilisé pour charger complètement toutes les informations d'une classe (l'index ne contient que le nom).
Il semble donc qu'il ne s'agisse que d'une optimisation. Personnellement, je ne l'inclurais pas dans le contrôle de la source à moins que vous ne trouviez qu'il fait une grand la différence avec les performances : à mon avis, elle ne restera vraiment valable que si une seule personne travaille sur le projet à la fois. (S'il est important et qu'il change régulièrement, vous pourriez trouver que cela ajoute une surcharge significative au référentiel également. Je n'ai pas vérifié pour voir quelle est la taille réelle, mais cela vaut la peine de vérifier).
Ce sont juste des données de complétion de code mises en cache. Comme l'explique l'article dont Jon a donné le lien, la raison principale est d'économiser de la mémoire, bien qu'ils vous évitent d'attendre que MD analyse tous les fichiers sources et les assemblages référencés lorsque vous ouvrez un projet.
Les fichiers pidb peuvent être régénérés assez rapidement, il n'y a donc aucun avantage à les conserver dans le VCS. En effet, en plus de la surcharge du dépôt VCS, cela pourrait également causer des problèmes si les gens utilisent différentes versions de MD avec différents formats pidb, donc je recommande fortement de ne pas les garder dans le contrôle de source.