Visual Studio 2010 Beta 2 を評価しているときに、変換されたディレクトリで、vcprojファイルがvcxprojファイルになっていることがわかりました。各プロジェクトの横には、フォルダー構造 (\Source Files、\Header Files など) の説明が含まれているように見えるvcxproj.filterファイルもあります。
これらのフィルター ファイルはユーザーごとに保持する必要があると思いますか、それとも開発グループ全体で共有して SCC にチェックインする必要があると思いますか?
チェックインしようというのが今の考えなのですが、そうしない理由や、チェックインしなければならない正当な理由があるのではないかと思っています。
明らかな利点は、私が他の人のマシンを見ている場合にフォルダー構造が一致することですが、おそらく彼らは物事を論理的に再編成したいのでしょうか?
意図的に.filterをプルしました。.vcxprojMSBuild形式に変換したときの.vcprojからのファイル情報。1つの理由は、フィルターが純粋に論理的なビューであり、チームメンバーごとに異なるビューが必要になる可能性があるということです。もう1つは、プロジェクトファイルのタイムスタンプをチェックし、変更された場合は再構築をトリガーするようにビルドが設定される場合があることです。これは、ビルドするソースファイルや設定が異なることを意味する場合があるためです。実際にビルドがそのようにトリガーされて出荷されたかどうかを思い出してください。ただし、フィルターが変更されたという理由だけでビルドに影響を与えないため、再構築をトリガーしたくないという考えでした。
以前のバージョンの Visual Studio (少なくともバージョン 6.0 および 2008) は、その情報を独自のプロジェクト ファイル (それぞれ .dsp および .vcproj ファイル) に保存します。もちろん、これは SCC に追加するのに適しています。
この .filter ファイルを SCC に含めない理由が思いつきません
Git を使用すると、.filter ファイルをマージ用のユニオンとして扱うようにマークして、マージを簡単にできることがわかりました。次の行を追加するだけです。
*.vcxproj.filters merge=union
.gitattributes ファイルに追加します。
詳細については、「. gitattributes を使用してマージの競合を回避する」を参照してください。