我应该将.vcxproj.filter文件添加到源代码管理中吗？

Question

我应该将.vcxproj.filter文件添加到源代码管理中吗？

jsc*_*edl 160 c++ version-control visual-studio-2010 visual-studio visual-c++-2010

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

您是否认为这些过滤器文件应该按用户保留,还是应该在整个开发组中共享并检入SCC？

我目前的想法是检查它们,但我想知道是否有任何理由不这样做,或者也许是我应该检查它们的好理由.

显而易见的好处是,如果我正在查看其他人的机器,文件夹结构将匹配,但也许他们想要在逻辑上重新组织事物？

Answer 1

小智 106

我们故意拉了.filter.当我们转换为.vcxproj MSBuild格式时,文件信息来自.vcproj.一个原因正是你所指出的,过滤器纯粹是一个逻辑视图,不同的团队成员可能想要不同的视图.另一个是,有时构建设置为检查项目文件的时间戳,并且如果它已经改变则触发重建 - 因为这可能意味着要构建不同的源文件,或者不同的设置等等.我不这样做回想一下,如果我们实际上发布了构建触发方式,但我们的想法是我们不想仅因为过滤器发生变化而触发重建,因为它们不会影响构建.

我分开对待它们.就我而言,作为项目状态的一部分,必须保留的废话越少越好,所以我认为这是一个很好的决定. (9认同)
如果我们不想使用任何抽象/逻辑树但只看到普通文件系统,我们可以完全禁用这些过滤器吗？ (6认同)
对于自动重建,您构建if*any*文件已更改(例如源),所以现在没有任何更改,除了我们还有另一个要管理的文件. (3认同)
换句话说,您将两个文件视为一个文件.我认为其他任何人都不会单独对待它们.这是一个不错的主意,但对现实世界的实践进行一些思考会有很长的路要走(比如将运行时放在WinSxS中) (3认同)
@JohanBoule:我完全同意!他们应该刚刚废弃了IDE中的过滤器.已经有一个逻辑树结构,它被称为"文件系统".目前存在大量重复 - 每个文件都必须添加到文件系统,构建脚本(vcxproj),过滤器(vcxproj.filters),源代码控制以及其他地方.它违反了DRY原则.**幸运的是**似乎过滤器文件是*可选*.您可以删除它们并使用IDE中的"显示所有文件"按钮.可惜它不是默认值. (3认同)
我们最终检查了它们并且对此安排感到满意.事实证明,如果它们具有相同的过滤器结构,我们可以更好地与其他开发人员一起工作. (2认同)

Answer 2

小智 56

以前版本的Visual Studio(至少版本6.0和2008)将这些信息存储在它们自己的项目文件中(分别是.dsp和.vcproj文件),这当然很适合添加到SCC.

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

Answer 3

par*_*y72 6

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

*.vcxproj.filters merge=union

Run Code Online (Sandbox Code Playgroud)

到您的 .gitattributes 文件。

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

但它说明了 `merge=union` 的作用 - 没有承诺其他任何内容。有了这些知识和一个非常广泛的想法 *.filter-files 是什么样子，很容易理解为什么 `merge=union` 是这些文件的一个好主意。 (2认同)

Answer 4

V. *_*nko 5

如果您使用CMake（或类似的构建工具）生成、等文件*.sln，则不应添加它，因为这些文件可能包含您的项目文件夹的完整路径，而其他仅包含您计算机的特定文件夹。*.vcxproj*.vcxproj.filters

归档时间：	16 年，2 月前
查看次数：	54346 次
最近记录：	7 年，3 月前