C++ 我应该将 .vcxproj.filter 文件添加到源代码管理中吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1826901/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Should I add .vcxproj.filter files to source control?
提问by jschroedl
While evaluating Visual Studio 2010 Beta 2, I see that in the converted directory, my vcprojfiles became vcxprojfiles. There are also vcxproj.filterfiles alongside each project which appear to contain a description of the folder structure (\Source Files, \Header Files, etc.).
在评估 Visual Studio 2010 Beta 2 时，我看到在转换后的目录中，我的vcproj文件变成了vcxproj文件。每个项目旁边还有vcxproj.filter文件，它们似乎包含文件夹结构的描述（\Source Files、\Header Files 等）。
Do you think these filter files should be kept per-user, or should they be shared across the whole dev group and checked into SCC?
您认为这些过滤器文件应该为每个用户保留，还是应该在整个开发组中共享并签入 SCC？
My current thinking is to check them in, but I wonder if there are any reasons not to do that, or perhaps good reasons why I should definitely check them in.
我目前的想法是将它们签入，但我想知道是否有任何理由不这样做，或者我绝对应该签入它们的充分理由。
The obvious benefit is that the folder structures will match if I'm looking at someone else's machine, but maybe they'd like to reorganize things logically?
明显的好处是，如果我正在查看其他人的机器，文件夹结构将匹配，但也许他们想从逻辑上重新组织内容？
采纳答案by jrbjazz
Previous versions of Visual Studio (at least versions 6.0 and 2008) store that information in their own project file (.dsp and .vcproj files respectively), which of course is good to add to SCC.
以前版本的 Visual Studio（至少是 6.0 和 2008 版）将该信息存储在它们自己的项目文件（分别为 .dsp 和 .vcproj 文件）中，这当然很适合添加到 SCC。
I cannot think of any reason to not include this .filter files in SCC
我想不出有什么理由不在 SCC 中包含这个 .filter 文件
回答by dan moseley
We intentionally pulled the .filter. file information out of the .vcproj when we translated to the .vcxproj MSBuild format. One reason is exactly what you pointed out, that the filters are purely a logical view, and different team members may want different views. The other is that sometimes the build is set up to check the timestamp of the project file, and trigger a rebuild if it has changed - because that may mean there are different source files to build, or different settings, etc. I don't recall if we actually shipped with the build trigging that way, but the idea was that we did not want to trigger a rebuild simply because the filters changed, as they don't affect the build.
我们故意拉了 .filter。当我们转换为 .vcxproj MSBuild 格式时，.vcproj 中的文件信息。一个原因正是您所指出的，过滤器纯粹是一种逻辑视图，不同的团队成员可能需要不同的视图。另一个是有时构建被设置为检查项目文件的时间戳，并在它发生更改时触发重建 - 因为这可能意味着要构建不同的源文件，或不同的设置等。我不回想一下我们是否真的以这种方式触发构建，但我们的想法是我们不想仅仅因为过滤器改变就触发重建，因为它们不会影响构建。
回答by parsley72
I just found that if you use Git you can mark .filter files to be treated as a union for merging to make it simpler. Just add the line:
我刚刚发现，如果您使用 Git，您可以将 .filter 文件标记为要合并的联合以使其更简单。只需添加以下行：
*.vcxproj.filters merge=union
to your .gitattributes file.
到您的 .gitattributes 文件。
See Using .gitattributes to avoid merge conflictsfor more details.
有关更多详细信息，请参阅使用 .gitattributes 以避免合并冲突。
回答by V. Panchenko
It should not be added in case you use CMake(or similar build tools) to generate files like *.sln, *.vcxproj, *.vcxproj.filtersetc., because this files may contain full path to your Project Folder and other only your computer's specific folders.
如果您使用CMake（或类似的构建工具）生成、等文件*.sln，则不应添加它，因为这些文件可能包含您的项目文件夹的完整路径，而其他仅包含您计算机的特定文件夹。*.vcxproj*.vcxproj.filters
