Si j’ajoute un nouveau fichier à un projet sous contrôle de source TFS, il extrait le fichier de projet et le fichier .vspscc correspondant à ce fichier de projet.
Le fichier de projet lui-même change (pour inclure le nouveau fichier), mais le fichier .vspscc ne change pas du tout. Pourquoi prendre la peine de le vérifier? Y a-t-il un moyen de le désactiver et, le cas échéant, le ferais-je?
Elle est vérifiée car, sous certaines conditions, elle sera modifiée… et par conséquent, elles ont été vérifiées par défaut. Je ne m’inquiéterais pas pour ça … ça ne fait pas mal, et si vous le désactivez, cela pourrait vous piquer à l’avenir de manière bizarre.
Selon ce post de Ben Ryan:
Team Foundation les utilise pour stocker des listes de fichiers exclus du contrôle de code source. Nous avons utilisé une partie de la couche d’intégration SCC existante dans Visual Studio pour intégrer Team Foundation, et ces fichiers étaient l’un des reports. Je devrai vérifier dans quelle logique il a fallu diviser ces parameters SCC en fichiers séparés au lieu de les placer dans les sections SCC des fichiers de solution et de projet.
Ce fichier est un vestige des implémentations VSS / TFS antérieures, comme l’a indiqué Paulo Santos.
Au niveau de la solution, je n’ai trouvé aucune utilisation fonctionnelle de ces fichiers. En 10 ans d’utilisation de TFS, je n’ai jamais vu ce fichier modifié. Vous pouvez supprimer ces fichiers .VSSCC, comme je le fais généralement pour mes solutions à source fermée.
Mais si vous supprimez le fichier .vsscc au niveau de la solution, vous obtiendrez un message d’erreur non destructif lors de la première ouverture du fichier de solution … uniquement après la création d’une nouvelle twig. Toute ouverture de solution ultérieure ne montrera plus le message d’erreur.
Mes normes d’installation TFS ont le fichier de solution seul dans le dossier racine, tous les projets sont sous des sous-dossiers. Comme ces fichiers .vsscc doublent le nombre de fichiers dans ma racine, je les supprime toujours.
Au niveau du projet, je laisse ces fichiers, car mon équipe n’ouvre jamais directement les fichiers de projet, mais uniquement les fichiers solution .SLN.
Pour mon équipe, je préfère la facilité du programmeur à ouvrir des solutions sur ce message d’erreur unique.