您如何管理由多个开发人员更改的源代码控制中的 .vcproj 文件？答案

【问题标题】：How do you manage .vcproj files in source control which are changed by multiple developers?您如何管理由多个开发人员更改的源代码控制中的 .vcproj 文件？
【发布时间】：2008-10-03 13:18:24
【问题描述】：

我们使用 Subversion 作为我们的源代码控制系统，并将 VisualStudio 项目文件 (vcproj) 存储在源代码控制系统中，我认为这是正常的。在 Subversion 中，我们不使用任何形式的文件锁定，因此如果两个开发人员同时在同一个项目上工作，并且都向项目中添加文件或更改设置，那么第二个提交的人必须合并更改。

您如何合并这些更改？

vcproj 文件只是文本文件，因此可以手动编辑它们，但它们不太适合手动编辑，尤其是初级开发人员。

我能想到的方法是

从 svn 获取最新版本并手动重新添加所有本地更改
手动编辑文件以解决自动合并中的任何冲突
实施某种形式的锁定方案以防止同时更改
在开发人员之间达成一致，以免他们同时进行更改

目前我们正在使用手动重新添加所有更改的第一个选项，但这很耗时，我想知道是否有更好的方法。

对于源文件，自动合并功能大部分时间都有效，我们不会遇到很多冲突。

【问题讨论】：

您可能会发现，如果您经常遇到签入冲突，则可以通过更改项目树的组织方式来受益。 IE：与其拥有一个包含 500 个文件的 .vcproj，而是拥有 1 个包含 50 个文件的项目，这些文件链接到 9 个库，每个库包含 50 个文件。如果您发现无法将项目拆分为单独的库，那么花费时间来实现这一点可能最终会提高开发人员的效率，因为模块化不仅有助于维护项目文件。

标签： visual-studio svn merge

【解决方案1】：

我发现选项 2（手动编辑文件）通常工作得很好，只要您使用一个好的差异工具（我使用 WinMerge）。我遇到的主要问题是 Visual Studio 有时会重新排序文件。但是，如果你有一个好的 diff/merge 工具，那么它应该能够区分更改的内容和移动的内容。这很有帮助。

【讨论】：

这很难过。 2010 和 VCPROJ 文件必须手动维护，因此版本控制系统不会破坏它。
同意，+1。 95% 的情况下，更改非常小（例如从项目中添加或删除 1 或 2 个文件）并且会完美地合并。只要您不对项目文件进行大而全面的更改，并且在自动接受之前仔细查看合并的结果，就可以了。在合并不起作用的极少数情况下，您应该重新进行本地更改。

【解决方案2】：

您可能会发现 Project: Merge 或 Tools for SLN file 很有用

【讨论】：

【解决方案3】：

这是一个棘手的问题，我认为是 Visual Studio 架构的一个弱点。我们找到的方法是根本没有源代码控制中的项目文件，并有一个处理配置设置的构建脚本。

替代方案非常混乱，我们无法保证开发人员之间的构建或环境一致。这导致了大量的下游集成问题，最终我们采取了从源代码控制中删除项目文件的严厉步骤。

开发人员的环境仍然可能会出现偏差，但当他们尝试自己构建时就会出现这种情况。

【讨论】：

【解决方案4】：

在这里使用 TFS，但我认为这没有什么区别。
我们也不锁定，有时还要处理合并项目文件。我从来没有发现它是那么复杂或很大的问题。我们很少遇到无法自动合并的问题，而且手动合并过程非常简单。

对此只有一个警告：经常检查！如果您对项目结构进行了重大更改并且没有立即将它们签入，那么这些更改可能会开始加剧以后合并的复杂性。如果我对项目结构进行重大更改，我通常会提醒每个人。我会要求他们都检查他们当前的工作，然后自己处理合并。

【讨论】：

【解决方案5】：

我最近发现了这个：http://www.codeproject.com/KB/macros/vcproj_formatter.aspx 如果您在 vcproj 文件及其修改版本上运行此工具，那么您可以使用您喜欢的文本合并工具轻松地将它们合并在一起，此外，结果是一个更紧凑、漂亮的 vcproj 文件。

【讨论】：

【解决方案6】：

选项 1 和 2 不是相互排斥的 - 如果开发人员是初级水平，让他们使用选项 1（重新获取项目文件并重新进行更改），如果这对他们来说更舒服的话。对于更高级的开发人员，选项 2（使用合并工具进行合并）非常好。

我认为这是目前没有灵丹妙药的情况 - 有时合并是一种痛苦。

【讨论】：

【解决方案7】：

我们使用差异工具 (WinMerge) 来合并更改。项目文件（大部分）是非常直接的 XML。不过，这里的关键是，合并时绝不应该有任何意外，因为良好的沟通是有效源代码控制的基石的一部分。

同时对项目进行更改完全没问题，只要人们进行交流。

【讨论】：

嘿。我的大脑对你的最后一句话做了一个小的替换。 “同时更改完全没问题……只要我先签到”。 :)
如果您有超过 10 名开发人员或在多个地点或合作区工作，这根本不够可靠，无法押注您的开发。
我完全不同意。如果你有问题那么你做错了。这正是源代码管理应该解决的问题！