Visual Studio 2010 Beta 2を評価しているうちに、変換されたディレクトリで私のvcprojファイルがvcxprojになりました。 vcxproj.filter各プロジェクトには、フォルダ構造（\ソースファイル、\ヘッダーファイルなど）の説明が含まれているように見えます。.vcxproj.filterファイルをソース管理に追加する必要がありますか？
これらのフィルタファイルはユーザーごとに保持する必要がありますか、またはdevグループ全体で共有してSCCにチェックインする必要がありますか？
私の現在の考え方は、それらをチェックすることですが、その、または私は間違いなく、それらを確認する必要がありますなぜ、おそらく正当な理由を行うにはない任意の理由があるのだろうか。
明白な利点は、そのフォルダ構造であります私が他の誰かのマシンを見ていればマッチしますが、論理的に物事を再編成したいのですか？
以前のバージョンのVisual Studio（少なくともバージョン6.0と2008）は、その情報をそれぞれ独自のプロジェクトファイル（.dspファイルと.vcprojファイル）に保存しますが、これはもちろんSCCに追加するのに適しています。
私は、我々が意図的に.filterを引っ張っSCC
でこの.filterファイルをインクルードしないように何らかの理由を考えることはできません。 .vcxproj MSBuild形式に変換したときの.vcprojからのファイル情報。 1つの理由はまさにあなたが指摘したことです。フィルターは純粋に論理的なビューであり、異なるチームメンバーは異なるビューを望むかもしれません。 もう1つは、プロジェクトファイルのタイムスタンプをチェックし、変更された場合に再ビルドをトリガするようにビルドが設定されることがあることです。ビルドするソースファイルや設定などが異なる可能性があります。ビルドに影響を与えないので、フィルタが変更されただけで再構築をトリガしたくないという考えがありました。
Gitを使用すると、.filterファイルをマージするためのユニオンとして扱われるようにマークすることができます。 .gitattributesファイルに
*.vcxproj.filters merge=union
の行を追加するだけです。
詳細はUsing .gitattributes to avoid merge conflictsを参照してください。
上記のリンクでは、この.filtersファイルにgitattributesファイルに記載されている "共用体"が含まれている必要があります。 – ollydbg23
私はあなたと一緒です。私はそれをチェックした。ありがとう！ – jschroedl