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

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

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

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

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


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

Ответы (4)


arrow_upward
62
arrow_downward

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

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

person jrbjazz    schedule 02.12.2009
comment
Я с тобой. Я проверил. Спасибо! - person jschroedl; 03.12.2009

arrow_upward
115
arrow_downward

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

person dan moseley    schedule 15.05.2010
comment
для автоматических перестроек вы строите, если какой-либо файл был изменен (например, исходный код), поэтому теперь ничего не изменилось, за исключением того, что у нас есть еще один файл для управления. - person gbjbaanb; 16.05.2010
comment
В итоге мы проверили их и до сих пор довольны такой договоренностью. Оказывается, нам будет приятнее работать с другими разработчиками, если у них будет такая же структура фильтров. - person jschroedl; 17.05.2010
comment
Другими словами, вы управляете обоими файлами, как если бы они были одним целым. Не думаю, что кто-то еще будет относиться к ним отдельно. Это хорошая идея, но немного подумать о реальных практиках могло бы иметь большое значение (например, размещение среды выполнения в WinSxS). - person gbjbaanb; 20.05.2010
comment
Я согласен с предыдущими комментариями. Мы также относимся к обоим так, как если бы они были одним целым. Это кажется очень непрагматичным и (раздражающим разработчиков) выбором, который они сделали для разделения этих файлов. - person David; 19.10.2011
comment
К ним отношусь отдельно. Насколько я понимаю, чем меньше мусора нужно сохранить как часть состояния проекта, тем лучше, так что я думаю, что это хорошее решение. - person rwallace; 03.03.2013
comment
Можем ли мы полностью отключить эти фильтры, если мы не хотим использовать какое-либо абстрактное / логическое дерево, а просто видим простую файловую систему? - person Johan Boulé; 24.08.2014
comment
@JohanBoule: Я полностью согласен! Им следовало просто отказаться от фильтров в среде IDE. Уже существует логическая древовидная структура, которая называется файловой системой. В настоящее время существует много дублирования - каждый файл нужно добавить в файловую систему, в сценарий сборки (vcxproj), фильтры (vcxproj.filters), систему управления версиями и, возможно, где-то еще. Это нарушает принцип СУХОЙ. К счастью, кажется, что файлы фильтров являются необязательными. Вы можете просто удалить их и использовать кнопку «Показать все файлы» в среде IDE. Жалко, что это не по умолчанию. - person Yakov Galka; 25.04.2017

arrow_upward
6
arrow_downward

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

*.vcxproj.filters merge=union

в ваш файл .gitattributes.

Дополнительные сведения см. В разделе Использование .gitattributes для предотвращения конфликтов слияния.

person parsley72    schedule 10.01.2017
comment
В указанной ссылке не сказано, что этот файл .filters должен иметь объединение, упомянутое в файле gitattributes. - person ollydbg23; 27.01.2018
comment
Но это говорит о том, что делает merge=union - больше ничего не обещано. Обладая этими знаниями и очень обширным представлением о том, как выглядят файлы * .filter, легко понять, почему merge=union - хорошая идея для этих файлов. - person Peter Schneider; 31.07.2018

arrow_upward
5
arrow_downward

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

person V. Panchenko    schedule 17.11.2018