处理版本控制系统上的多用户工作

Question

我可以想象多个程序员如何同时在同一代码库上密集工作的系统。

• 我认为当连接到代码库的程序员之一开始编辑一个文件时，服务器上的版本控制系统应该能够锁定一个文件进行编辑

• 有关代码库更改的实时通知并将更新的文件推送给其他人（通过通知或自动更新）

• 即时谈论变更集，显示提交和差异（像 Trac 或类似的一些集成源代码历史浏览器也可以）

• 与某些特色 IDE（如 Netbeans 或 Eclipse）集成的解决方案

但是什么有一些便宜的（完美的开源）解决方案吗？
您测试过哪些系统并可以推荐我使用哪些系统？

编辑1：
建议的解决方案不必提供我在问题中编写的所有功能。 该列表是我想象的该系统可能具有的列表，而不是需求列表。 问题更多是关于如何解决“svn/cvs/etc.. 上的多用户工作”以及您最喜欢哪种解决方案。

编辑2
@thiton 评论的一点点
需要指出的是，存在一种称为 RCS（修订控制系统）的东西。据我所知，RSC 是 CVS 的祖先。 CVS 作为一个概念在 svn、git、mercurial、bazaar 等中实现...
我们从 RSC 转向其后继者的原因是，旧的做事方式会减慢团队工作的速度并使团队工作变得过于复杂。锁定文件并仅在编辑结束后才释放它们，这不是我们想要的方式。 现在，由于我们可以撤消对单个文件的更改（将其恢复到给定的修订号），从而修复我们或其他的错误，因此有必要这样做。
所以我划掉了清单上的第一点（注意它不是按优先级降序写下来的），并感谢@thiton 提醒我这一点。

Answer 1

应用程序生命周期管理 (ALM) 和大量 ALM 工具包涵盖了您提出的问题。此类工具包的示例：

1. Atlassian 产品：Jira （问题跟踪），Fisheye（差异查看器/存储库查看器），Crucible（代码审查工具）和其他（Confluence、Bamboo、Clover）。这是我向遇到您所描述的问题的任何人推荐的一系列工具。我认为我不应该介绍 Jira 的功能，只要它可能是最流行的问题跟踪系统。可以使用 将问题跟踪与版本控制集成>Subversion-Jira 插件。安装并配置此插件后，可以在提交注释中提及问题号（#234、#687 等）。然后，Jira 将显示特定问题下的所有提交，因为这些提交促成了该问题。如果您想查看这些提交的内容，您将需要Fisheye。它不仅允许您查看，还可以评论更改并将更改集以链接的形式放置。如果您有 Fisheye，那么引用变更集或提交就不会有问题。另一个级别的协作是Crucible。它允许对您在版本控制系统中由其他用户执行的所有提交进行代码审查。它非常灵活。例如，您可以在特定提交中的特定源代码行前面添加注释，动态创建子任务并将您自己的代码放入审阅注释中。恕我直言，Atlassian 工具是金钱能买到的最好工具。正如您所看到的，它们不是免费的。
   这就是为什么你可能不喜欢它。不过，还有其他选择。
2. ViewVC - 存储库浏览/diff 查看器工具。可以考虑是Fisheye的替代品。
3. WebSVN - 另一个存储库浏览/差异查看器工具。
4. 提交监控。您并不总是希望通过电子邮件收到通知。在这种情况下，Commit Monitor（在 Windows 下运行）可能会派上用场。当有人提交时，它会在桌面上显示弹出窗口。从我的角度来看，这比接收电子邮件更方便。此外，您可以直接在提交监视器中查看最近提交的列表。如果您无法在 Windows 上运行，请使用 Wine 或 Subversion 提交监视器。
5. 使用变更列表。 subversion 和 TortoiseSVN 都有变更列表功能（它不一样）作为变更集），并且它经常派上用场。您需要了解的是，变更列表与问题的概念类似，但在版本控制级别上。

除了所有提到的工具之外，我建议对 subversion 存储库使用以下存储库结构：

    /project
        /trunk
        /tags
            /builds
                /PA
                /A
                /B
            /releases
                /AR
                /BR
                /RC
                /ST
        /branches
            /experimental
            /maintenance
                /versions
                /platforms
            /releases

此存储库结构侧重于版本控制的以下重要方面：

1. 使用分支
2. 始终知道为什么需要分支
3. 使用标签
4. 始终知道为什么需要标签:)
5. 使用 svn:externals。这意味着您应该尝试模块化您的应用程序并考虑模块之间的依赖关系。
6. 使用“每个项目存储库”方法。它将有助于模块化您的应用程序并避免频繁出现的错误。
7. 使用持续集成。它将有助于跟踪存储库中分支的当前状态。实际上，持续集成可以被认为对协作活动和团队沟通产生巨大影响。如果您之前没有使用过持续集成并且不知道从哪里开始，那么有很多选择：CruiseControl（还有 CruiseControl.NET 和 CruiseControl.rb）、Hudson、Jenkins、Bamboo、TeamCity、Continuum 等。

我提到了这个存储库结构，因为当存在这样的约定时它会很有帮助：

1. 通信。您不需要在提交日志中写入大量内容来描述您正在做的事情 - 您只需将相应的工件添加到 VCS 中即可。
2. 降低做出错误举动的机会。很多时候，开发人员迫切需要做一些事情，但不知道到底如何做。这种情况很容易做出错误的举动，因此就提出了与他人沟通和互动的必要性。当此类常见动作的列表（就 VCS 而言）不存在于 wiki 上的某个位置（人们应该尝试找到的位置），而是立即存在于存储库中时，它会很有帮助。
3. 问题较少。在大多数情况下，在存储库中拥有这样的结构是不言自明的。关于如何在 VCS 中执行操作的问题越少越好。

Answer 2

您可以使用 Subversion (svn) 做您想做的事情。我喜欢的实时通知是每次提交后发送的包含更改差异的电子邮件。一开始这有点奇怪，但一旦你习惯了，你就会想念它，如果它不可用。

每个开发人员都有电子邮件并且知道如何处理它。如果您不想被打扰，只需关闭邮件客户端即可。由于它在服务器上运行，因此它适用于所有工具。您可以找到有关此问题的教程。

如果一名开发人员正在编辑文件，我不会锁定该文件。在这种情况下，所有其他开发人员都无法进行更改，并且每个人的速度都会变慢。如果您的业务逻辑有很长的帮助程序类，那么这种情况会很快发生。

并且不自动更新工作副本。如果您正在构建项目或更改文件，则很容易导致冲突。在最好的情况下，您只需要再次构建它，但在最坏的情况下，您会丢失自上次提交以来的所有数据。

如果您更喜欢分布式版本控制系统，也可以使用 git 和 Mercurial 来完成挂钩脚本方法。在这种情况下，挂钩在您选择作为主库的存储库上运行。

Answer 3

如果您确实希望在其他人提交更改时在工作树中进行实时更新，那么您需要像 ClearCase 这样的东西，但这绝对不便宜（我和我认识的大多数人都讨厌它）。

否则，如果您希望在准备好后手动拉取其他人的更改，则您在编辑 2 中列出的所有 VCS 都会执行电子邮件通知（您需要自己编写一个挂钩脚本，在大多数情况下）例），并且大多数都有图形界面，可以进行差异和其他操作。

您没有提供足够的信息来决定推荐哪个。您必须决定是想要集中式还是分布式，除此之外，这实际上只是一个品味问题。我不知道有任何集成的聊天工具，但是，嘿，设置一个 IRC 服务器并不难，或者只是在 freenode 上创建一个房间（如果你不做任何保密的事情）。

SVN、Git 和 Bazaar 都是不错的选择。我没有使用过 Mercurial，但我听说过它的一些好消息。 Arch 可以用，但我不喜欢它。 CVS 可以工作，但是带有变更集的东西将使历史（更）以后更容易理解。

其他 VCS 也可用。

Answer 4

关于版本控制系统的使用有多种思想流派。

我的偏好是尝试让每个即将推出的功能在单独的功能分支中运行（无论多小）。分配给该功能的人员只能进行自己的更改；没有来自其他开发者的干扰。

错误修复（除了真正微不足道的错误之外）也首先作为单独的分支进行，只是为了保持主干线的稳定和干净。最新的主干版本始终对应于产品的最后交付版本（版本）。

当准备新版本时，如果只有一个更改即将到来，并且该更改本身基于先前交付的版本，则可以针对分支版本运行测试，并且在新版本发布时，从分支只是集成到主干版本中。像 cvs 和 svn 这样的版本控制系统对这种合并操作有很好的支持（我自己没有使用过 git，但了解分支和合并在那里也处理得很好）。

如果有几个不同的更改需要集成，我更喜欢创建一个单独的“集成”分支，我首先将所有要集成的更改一一收集到该分支。同样，当存在冲突编辑时（即单个代码文件的一个位置有两个不同的更改），版本控制系统会进行标记。可以理解的是，他们无法判断是否存在由几个不同的变化引起的功能冲突。因此，每次集成后至少需要一些监督，最好还需要测试。

然后，当所有单独的更改都已集成到集成分支时，可以对其进行彻底测试，并在准备发布时再次合并到主干。如果需要做进一步的修正，可以在原来的特征分支中进一步发展，然后将修正的agani集成到集成分支中。

这种方式非常适合快速错误纠正响应，因为主干始终包含最新版本。它还非常适合投机开发，因为独特的功能分支仅在集成时影响主干线。此外，功能可以在多个发布周期内工作，因为发布不会影响功能分支中正在进行的开发。这样，“巴士因素”（如果一名开发人员被巴士碾过会发生什么情况）也减少了；不完整甚至无法编译的代码可以在功能分支中签入——如果有人因任何原因缺勤，所有完成的工作都可供其他开发人员使用。此外，工作站灾难不会引起重大担忧，就像工作站可以轻松容纳一周的未签入、未备份的开发工作一样。

随着新版本的发布，是否始终将长期存在的功能分支更新到最新版本是一个策略问题，并且也可能取决于上一个版本中的内容。另一个政策问题是整合分支的所有权；是否有某个人负责收集所有功能分支更改并进行所需的小更改以使它们适应其他更改，或者每个功能开发人员/团队是否负责将特定功能分支的更改获取到集成分支。我喜欢单独的“发布构建者”（当然，他通常是功能开发人员之一）。

至少在我的现实中，如果 3-4 名开发人员能够相互沟通（共享办公空间是首选方式），他们似乎可以在一个分支中很好地工作。他们确实自己安排工作，并且可以避免踩到对方的脚趾。此外，单独的功能分支似乎很少相互接触相同的文件，因此大多数合并周期都相当轻松（并且可以通过更改描述来预测痛苦的周期）。另一方面，如果变更没有在分支中隔离，即使单个开发人员在多个不同但同时发生的变更任务上执行多任务，也会遇到麻烦。

所以，总结一下：不要锁定文件，而是拥有良好的版本控制系统，勇敢地利用分支，并在合并分支更改时保持警惕。