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

169

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

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

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

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

— 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т. Д., Поскольку эти файлы могут содержать полный путь к папке проекта и другие только для определенных папок вашего компьютера .

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