.vcxproj.filter ファイルをソース管理に追加する必要がありますか?
-
11-09-2019 - |
質問
Visual Studio 2010 Beta 2 を評価しているときに、変換されたディレクトリに次のことが表示されます。 vcproj ファイルはこうなった vcxproj ファイル。もあります vcxproj.フィルター 各プロジェクトの横に、フォルダー構造の説明が含まれているように見えるファイル (\Source Files、\Header Files など)。
これらのフィルター ファイルはユーザーごとに保持する必要があると思いますか、それとも開発グループ全体で共有して 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
など。このファイルにはプロジェクト フォルダーやその他のフォルダーへのフル パスが含まれている可能性があるためです。 コンピューターの特定のフォルダーのみ.