我应该将 .vcxproj.filter 文件添加到源代码管理吗？
在评估 Visual Studio 2010 Beta 2 时，我发现在转换后的目录中，我的 vcproj 文件变成了 vcxproj 文件。每个项目旁边还有 vcxproj.filter 文件，其中似乎包含文件夹结构的描述（\源文件、\头文件等）。
您认为这些过滤器文件应该按用户保留，还是应该在整个开发组中共享并签入 SCC？
我目前的想法是签入它们，但我想知道是否有任何理由不这样做，或者也许有充分的理由为什么我一定要签入它们。
明显的好处是，如果我正在查看，文件夹结构将匹配别人的机器，但也许他们想逻辑地重新组织事物？
While evaluating Visual Studio 2010 Beta 2, I see that in the converted directory, my vcproj files became vcxproj files. There are also vcxproj.filter files alongside each project which appear to contain a description of the folder structure (\Source Files, \Header Files, etc.).
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?
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我们故意拉掉了.filter。当我们转换为 .vcxproj MSBuild 格式时，将文件信息从 .vcproj 中取出。
一个原因正是您所指出的，过滤器纯粹是一种逻辑视图，不同的团队成员可能需要不同的视图。
另一个是，有时构建会被设置为检查项目文件的时间戳，并在它发生更改时触发重建 - 因为这可能意味着需要构建不同的源文件或不同的设置等。我不这样做回想一下，如果我们实际上以这种方式触发构建，但我们的想法是，我们不想仅仅因为过滤器发生变化而触发重建，因为它们不会影响构建。
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.
以前版本的 Visual Studio（至少版本 6.0 和 2008）将该信息存储在自己的项目文件（分别为 .dsp 和 .vcproj 文件）中，这当然可以很好地添加到 SCC。
我想不出有什么理由不将此 .filter 文件包含在 SCC 中
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.
I cannot think of any reason to not include this .filter files in SCC
如果您使用
CMake（或类似的构建工具）生成*.sln、*.vcxproj、< 等文件，则不应添加它code>*.vcxproj.filters 等，因为此文件可能包含您的项目文件夹和其他仅您计算机的特定文件夹的完整路径。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.我刚刚发现，如果你使用 Git，你可以将 .filter 文件标记为合并的联合，以使其更简单。只需将行：添加
到您的 .gitattributes 文件中。
有关更多详细信息，请参阅使用 .gitattributes 避免合并冲突。
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:
to your .gitattributes file.
See Using .gitattributes to avoid merge conflicts for more details.