Должен ли я добавить файлы .vcxproj.filter в систему контроля версий?

169

Оценивая Visual Studio 2010 Beta 2, я вижу, что в преобразованном каталоге мои файлы vcproj стали файлами vcxproj . Кроме того, в каждом проекте есть файлы vcxproj.filter, которые содержат описание структуры папок (\ Source Files, \ Header Files и т. Д.).

Как вы думаете, эти файлы фильтров должны храниться для каждого пользователя, или они должны быть общими для всей группы разработчиков и проверены в SCC?

В настоящее время я думаю о том, чтобы проверить их, но мне интересно, есть ли причины не делать этого, или, может быть, есть веские причины, по которым я должен обязательно их проверить.

Очевидное преимущество заключается в том, что структуры папок будут совпадать, если я смотрю на чужую машину, но, возможно, они хотели бы логически реорганизовать вещи?

c++ visual-studio-2010 visual-studio version-control visual-c++-2010 jschroedl
источник

Ответы:

59

Предыдущие версии Visual Studio (по крайней мере версии 6.0 и 2008) хранят эту информацию в своем собственном файле проекта (соответственно файлы .dsp и .vcproj), который, конечно, хорошо добавить в SCC.

Я не могу придумать причину не включать эти файлы .filter в SCC

jrbjazz
источник
Я с тобой. Я проверил это. Спасибо!
jschroedl
111

Мы намеренно вытащили .фильтр. файл информации из .vcproj при переводе в формат .vcxproj MSBuild. Одна из причин - именно то, на что вы указали, что фильтры являются чисто логическим представлением, и разные члены команды могут хотеть разных представлений. Другое заключается в том, что иногда сборка настраивается для проверки метки времени файла проекта и запускает пересборку, если она изменилась - потому что это может означать, что для сборки нужны разные исходные файлы или другие настройки, и т. Д. Я не Напомним, если мы действительно поставляли сборку таким способом, но идея заключалась в том, что мы не хотели запускать перестройку просто потому, что фильтры изменились, поскольку они не влияют на сборку.

Дэн Мозли
источник
3
для автоматических перестроений вы создаете, если какой-либо файл изменился (например, исходный код), поэтому теперь ничего не изменилось, за исключением того, что у нас есть еще один файл для управления.
gbjbaanb
3
Мы закончили регистрацию их и были счастливы с этим соглашением до сих пор. Оказывается, нам лучше работать с другими разработчиками, если они имеют одинаковую структуру фильтра.
jschroedl
9
Я отношусь к ним отдельно. Насколько я понимаю, чем меньше дерьма, которое нужно сохранить как часть состояния проекта, тем лучше, поэтому я считаю, что это хорошее решение.
rwallace
6
Можем ли мы вообще отключить эти фильтры, если мы не хотим использовать какое-либо абстрактное / логическое дерево, а просто видим простое файловое устройство?
Йохан Буле
4
@JohanBoule: Я полностью согласен! Они должны были просто отказаться от фильтров в IDE. Уже существует логическая древовидная структура, и она называется «файловая система». В настоящее время существует много дубликатов - каждый файл должен быть добавлен в файловую систему, в скрипт сборки (vcxproj), фильтры (vcxproj.filters), управление исходным кодом и, возможно, где-то еще. Это нарушает СУХОЙ принцип. К счастью, кажется, что файлы фильтров не являются обязательными . Вы можете просто удалить их и использовать кнопку «Показать все файлы» в IDE. Жаль, что это не по умолчанию.
Яков Галка
5

Я только что обнаружил, что если вы используете Git, вы можете пометить файлы .filter, которые будут рассматриваться как объединение, для упрощения слияния. Просто добавьте строку:

*.vcxproj.filters merge=union

в ваш файл .gitattributes.

См. Использование .gitattributes, чтобы избежать конфликтов слияния для получения дополнительной информации.

parsley72
источник
Упомянутая ссылка не говорит, что этот файл .filters должен иметь "union", упомянутый в файле gitattributes.
ollydbg23
2
Но это говорит о том, что merge=unionделает - больше ничего не было обещано. Имея это знание и очень широкое представление о том, как выглядят * .filter-файлы, легко понять, почему merge=unionэто хорошая идея для этих файлов.
Питер Шнайдер
1

Его не следует добавлять в случае, если вы используете CMake(или аналогичные инструменты сборки) для создания таких файлов, как *.sln, *.vcxprojи *.vcxproj.filtersт. Д., Поскольку эти файлы могут содержать полный путь к папке проекта и другие только для определенных папок вашего компьютера .

В. Панченко
источник