Чи слід додати .vcxproj.filter файли до керування джерелом?

169

При оцінці Visual Studio 2010 Beta 2, я бачу , що в реформованій директорії, мої vcproj файли стали vcxproj файлів. Поряд з кожним проектом є також файли vcxproj.filter, які, як видається, містять опис структури папок (\ вихідні файли, \ файли заголовків тощо).

Як ви вважаєте, ці файли фільтрів повинні зберігатися на кожного користувача, або їх слід ділити по всій групі розробників і перевіряти в SCC?

Моє теперішнє мислення полягає в тому, щоб перевірити їх, але мені цікаво, чи є причини, щоб цього не зробити, чи, можливо, вагомі причини, чому я повинен обов'язково перевірити їх.

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

— jschroedl
джерело

59

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

Я не можу придумати жодної причини, щоб не включати ці .filter-файли до SCC

— jrbjazz
джерело

Я з тобою. Я перевірив це. Дякую!

— jschroedl

111

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

— дан мозелі
джерело

3

для автоматичної перебудови ви будуєте, якщо який-небудь файл змінився (наприклад, джерело), тому тепер нічого не змінилося, крім у нас є ще один файл для управління.

— gbjbaanb

3

Іншими словами, ви керуєте обома файлами так, ніби вони були одним. Я не думаю, що ніхто інший також не буде ставитися до них окремо. Приємна ідея, але трохи думки про практику в реальному світі пройшли б довгий шлях (як, наприклад, встановлення часу виконання в WinSxS)

— gbjbaanb

9

Я ставлюся до них окремо. Наскільки я переживаю, чим менше лайно, яке потрібно зберегти в рамках проекту, тим краще, тому я вважаю, що це хороше рішення.

— rwallace

6

Чи можемо ми взагалі відключити ці фільтри, якщо ми не хочемо використовувати якесь абстрактне / логічне дерево, а просто бачимо просту файлову систему?

— Йохан Буле

4

@JohanBoule: Я повністю згоден! Вони повинні були просто зняти фільтри в IDE. Вже є логічна структура дерева і вона називається "файлова система". В даний час дублювання багато - кожен файл повинен бути доданий до файлової системи, до сценарію збірки (vcxproj), фільтрів (vcxproj.filters), керування джерелами та, можливо, десь ще. Це порушує принцип сушеності. На щастя, здається, що фільтруючі файли необов’язкові . Ви можете просто видалити їх і скористатися кнопкою "Показати всі файли" в IDE. Шкода, що це не за замовчуванням.

— Яків Галка

5

Щойно я виявив, що якщо ви використовуєте Git, ви можете позначати файли .filter, які розглядаються як об'єднання для об'єднання, щоб зробити його простішим. Просто додайте рядок:

*.vcxproj.filters merge=union

у ваш .gitattributes файл.

Докладніше див. У розділі Використання .gitattributes, щоб уникнути конфліктів злиття .

— петрушка72
джерело

Згадане посилання не говорить про це .filters файл повинен мати "об'єднання", згадане у файлі gitattributes.

— ollydbg23

2

Але це говорить що merge=unionробить - нічого іншого не обіцяли. З урахуванням цих знань і дуже широкого уявлення про те, як виглядають * .filter-файли, легко зрозуміти, чому merge=unionце хороша ідея для цих файлів.

— Пітер Шнайдер

1

Він не повинен бути доданий в разі , якщо ви використовуєте CMake(або аналогічні інструменти для збірки) для створення файлів , таких як *.sln, *.vcxproj, і *.vcxproj.filtersт.д., тому що ці файли можуть містити повний шлях до папки проекту і іншим тільки певних папок вашого комп'ютера .

— В. Панченко
джерело