是否应将.vcxproj.filter文件添加到源代码管理中？

169

在评估Visual Studio 2010 Beta 2时，我看到在转换后的目录中，我的vcproj文件变成了vcxproj文件。每个项目旁边还有vcxproj.filter文件，这些文件似乎包含文件夹结构的描述（\ Source Files，\ Header Files等）。

您认为这些筛选器文件应按用户保留，还是应在整个开发人员组中共享并检入SCC？

我目前的想法是将它们检入，但是我想知道是否有任何理由不这样做，或者也许是为什么我一定要对其进行检入的充分理由。

明显的好处是，如果我查看其他人的计算机，则文件夹结构将匹配，但也许他们想按逻辑进行重组？

— 施罗德尔
source

59

Visual Studio的早期版本（至少为6.0和2008版本）将该信息存储在其自己的项目文件（分别为.dsp和.vcproj文件）中，这当然可以添加到SCC中。

我想不出任何理由不在SCC中包含此.filter文件

— 爵士乐
source

我和你在一起。我检查了一下。谢谢！

— jschroedl

111

我们有意拉了.filter。当我们转换为.vcxproj MSBuild格式时，.vcproj中没有文件信息。正是您所指出的一个原因，即过滤器纯粹是逻辑视图，不同的团队成员可能需要不同的视图。另一个是有时建立构建以检查项目文件的时间戳，并在更改后触发重新构建-因为这可能意味着要构建的源文件不同，或设置不同，等等。我没有回想一下，如果我们实际上是用这种方式触发了构建，但是我们的想法是我们不想仅仅因为过滤器发生了变化就触发了重建，因为它们不会影响构建。

— 丹·莫斯利
source

3

对于自动重建，如果任何文件已更改（例如，源文件），则进行构建，因此，除了我们还有另一个文件要管理之外，现在没有任何更改。

— gbjbaanb 2010年

3

换句话说，您将两个文件当作一个文件来管理。我认为其他人也不会分开对待它们。这是一个不错的主意，但对现实世界的实践的一些思考会走很长一段路（例如将运行时放入WinSxS中）

— gbjbaanb 2010年

9

我分开对待。就我而言，作为项目状态的一部分保留的废话越少越好，所以我认为这是一个不错的决定。

— rwallace

6

如果我们不想使用任何抽象/逻辑树，而只看一个普通的文件系统，是否可以完全禁用那些过滤器？

— JohanBoulé2014年

4

@JohanBoule：我完全同意！他们应该只是在IDE中取消了过滤器。已经有一个逻辑树结构，它被称为“文件系统”。当前有很多重复项-每个文件都必须添加到文件系统，构建脚本（vcxproj），过滤器（vcxproj.filters），源代码控制以及其他地方。它违反了DRY原则。幸运的是，筛选器文件似乎是可选的。您可以删除它们，然后在IDE中使用“显示所有文件”按钮。可惜这不是默认值。

— Yakov Galka '17

5

我刚刚发现，如果您使用Git，则可以将.filter文件标记为合并的联合，从而使其更简单。只需添加以下行：

*.vcxproj.filters merge=union

到您的.gitattributes文件。

有关更多详细信息，请参见使用.gitattributes避免合并冲突。

— 香菜72
source

提到的链接没有说这个.filters文件应该在gitattributes文件中提到“联合”。

— ollydbg23 '18

2

但这说明了什么merge=union-没有其他承诺。有了这些知识和一个非常广泛的想法，*。filter文件的外观如何，很容易看出为什么merge=union这些文件是个好主意。

— 彼得·施耐德

1

它不应该在你使用的情况下被添加CMake（或类似的生成工具）来生成诸如文件*.sln，*.vcxproj，*.vcxproj.filters等等，因为这个文件可能包含到项目文件夹和其他完整路径只有你的计算机的专用文件夹。

— 潘琴科
source