135

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

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

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

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

ответ

49

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

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

+0

Я с вами. Я проверил его. Спасибо! – jschroedl

90

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

+1

для автоматических перестроек, вы создаете, если * любой * файл изменился (например, источник), поэтому теперь ничего не изменилось, кроме того, что у нас есть еще один файл для управления. – gbjbaanb

+0

Мы закончили тем, что проверили их, и до сих пор были довольны этой договоренностью. Нам оказывается приятнее работать с другими разработчиками, если они имеют одну и ту же структуру фильтра. – jschroedl

+2

Другими словами, вы управляете обоими файлами, как если бы они были такими. Я не думаю, что кто-то другой будет относиться к ним отдельно. Его хорошая идея, но немного подумать о реальных практиках проделали бы долгий путь (например, положить runtime в WinSxS) – gbjbaanb

3

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

*.vcxproj.filters merge=union 

в ваш файл .gitattributes.

Для получения более подробной информации см. Using .gitattributes to avoid merge conflicts.

+0

Упомянутая ссылка не указала, что этот файл .filters должен иметь «union», упомянутый в файле gitattributes. – ollydbg23

Смежные вопросы