.vcxproj.filterファイルをソース管理に追加する必要がありますか？

Visual Studio 2010 Beta 2を評価していると、変換されたディレクトリで、vcprojファイルがvcxprojファイルになったことがわかります。各プロジェクトの横には、フォルダー構造の説明（\ Source Files、\ Header Filesなど）が含まれているように見えるvcxproj.filterファイルもあります。

これらのフィルターファイルはユーザーごとに保持する必要があると思いますか、それとも開発グループ全体で共有してSCCにチェックインする必要がありますか？

私の現在の考えはそれらをチェックインすることですが、それを行わない理由があるのか​​、あるいは私が間違いなくそれらをチェックインする必要があるのにはおそらく正当な理由があるのだろうかと思います。

明らかな利点は、他の人のマシンを見ているとフォルダ構造が一致することですが、おそらく論理的に再編成したいですか？

Visual Studioの以前のバージョン（少なくともバージョン6.0および2008）では、その情報を独自のプロジェクトファイル（それぞれ.dspファイルと.vcprojファイル）に保存します。もちろん、これはSCCに追加するのに適しています。

この.filterファイルをSCCに含めない理由は何も考えられません。

意図的に.filterをプルしました。.vcxproj MSBuild形式に変換したときの.vcprojからのファイル情報。1つの理由は、あなたが指摘したとおりです。フィルターは純粋に論理的なビューであり、異なるチームメンバーが異なるビューを必要とする場合があるためです。もう1つは、プロジェクトファイルのタイムスタンプを確認し、変更された場合に再ビルドをトリガーするようにビルドがセットアップされることがあります。これは、ビルドするソースファイルや設定が異なるなどの理由で発生する可能性があるためです。実際にビルドがそのようにトリガーされた状態で出荷されたかどうかを思い出してください。ただし、フィルターが変更されたためにビルドに影響を与えないため、再ビルドをトリガーしたくないという考えでした。

Gitを使用している場合、.filterファイルをマージ用のユニオンとして扱うようにマークし、それをより簡単にすることができることを発見しました。次の行を追加してください：

*.vcxproj.filters merge=union

あなたの.gitattributesファイルに。

詳細については、.gitattributesを使用してマージの競合を回避するをご覧ください。

それはあなたが使用した場合に追加すべきではないCMakeようなファイルを生成する（または類似のビルドツール）*.sln、*.vcxproj、*.vcxproj.filtersこのファイルは、あなたのプロジェクトフォルダおよびその他のフルパスが含まれている可能性があるため、などをのみ、コンピュータの特定のフォルダ。