Если я добавлю новый файл в проект под управлением источника TFS, он проверит файл проекта и соответствующий файл .vspscc для этого файла проекта.
Сам файл проекта изменяется (для включения нового файла), но файл .vspscc вообще не изменяется. Зачем это проверять? Есть ли способ отключить его от проверки и если есть, должен ли я?
Он проверяется, потому что при определенных условиях он будет изменен.. и, таким образом, они проверили его как вопрос дефолта. Я бы не стал беспокоиться об этом... ничего не причиняю вреда, и если вы отключите его, это может сильно укусить вас в будущем странным образом.
В соответствии с этот пост Бен Райана:
Team Foundation использует их для хранения списков файлов, которые были исключены из исходного элемента управления. Мы использовали часть существующего уровня интеграции SCC в Visual Studio для интеграции Team Foundation, и эти файлы были одним из переносов. Я должен проверить, в чем заключалась логика, чтобы разбить эти настройки SCC на отдельные файлы, а не размещать их в разделах SCC и файлах проекта.
Этот файл представляет собой задержку прошлых реализаций VSS/TFS, как опубликовал Пауло Сантос.
На уровне решения я не нашел функционального использования для этих файлов. За 10 лет использования TFS я никогда не видел, чтобы этот файл изменился. Вы можете удалить эти файлы .VSSCC, как я обычно делаю для своих закрытых исходных решений.
Но если вы удалите файл .vsscc на уровне решения, вы получите сообщение об ошибке неразрушающего обхода при первом открытии файла решения... только после создания новой ветки. Все последующие открытия решения не будут отображать сообщение об ошибке снова.
Стандарты настройки My TFS имеют файл решения только в корневой папке, все проекты находятся в подпапках. Поскольку эти файлы .vsscc удваивают количество файлов в моем корне, я всегда удаляю их.
На уровне проекта я оставляю эти файлы, так как моя команда никогда не открывает файлы проекта напрямую, только файлы .SLN.
Для моей команды я предпочитаю программисту легкость открытия решений в течение этого однократного сообщения об ошибке.