可交付成果的版本控制

Question

我们需要定期在多个不同位置的许多开发人员之间同步许多二进制文件（项目可执行文件和DLL），以便每个开发人员都有一个最新的环境来构建和测试。由于项目的性质，必须经常和按需更新（夜间更新是不够的）。这不是很好，但我们已经坚持了一段时间。

我们决定使用常规版本（源代码）控制系统：将所有内容作为二进制文件放入其中，在测试之前获取最新版本并在测试后签入更新的DLL。

它工作正常，但版本控制客户端有很多功能对我们没有意义，人们偶尔会感到困惑。

有没有更适合这项任务的工具？或者可能是一种完全不同的方法？

更新：

我需要澄清的是，它不是一个紧密集成的项目 - 更像是具有一堆“插件”的可扩展系统，包括第三方的插件。我们需要确保这些模块 - 插件与彼此的最新版本和核心很好地协同工作。最初考虑了建议的集中构建，但它不是一种选择。

Answer 1

我可能会看看rsync。

只需创建一个.CMD文件，其中包含对所有正确参数的rsync调用，并让人们调用它。 rsync在决定需要传输哪些文件时非常聪明，因此即使涉及大文件也会非常快。

rsync没有做什么是冲突解决（甚至是检测），但是在你描述的场景中，它更像是从rsync旨在处理的中心位置读取。

Answer 2

另一个选项是unison

Answer 3

您应该考虑持续集成并采用某种集中式构建过程。我只能想象你当前采用的那种地狱。

显然，这对保持本地文件同步无效，但我认为您的流程存在较大问题。

Answer 4

构建项目应该是一个集中的过程，以便更快地控制您的解决方案从长远来看会很困难。无论如何，这就是我要做的。

• 为其创建常用的存储库 源文件，资源， 每个项目的文档等。
• 为资源创建存储库。 会有最新的二进制文件 每个项目的版本以及 任何所需的资源，文件等 保持良好的文件夹结构 每个项目所以开发人员可以 直接“引用”文件。
• 为最终的buidl创建一个存储库 这将保持实际稳定 发布。这将获得稳定 文件，以自动方式完成（如果 可能）从登记入住 源。这将是真实的 产品，真正的版本 集成测试等。

虽然远非完美，但您将能够定义完善的协议。在这里检查你最新的dll，在这里生成最新来源的“真实”版本。

Answer 5

如何在可执行文件和库中嵌入“what”字符串。然后，您可以使用清单同步所需的版本列表。

我们倾向于使用CVS id字符串作为字符串的一部分。

const char cvsid[] = "@(#)INETOPS_filter_ip_$Revision: 1.9 $";

输入命令

what filter_ip | grep INETOPS

返回

INETOPS_filter_ip_$Revision: 1.9 $

我们为所有可交付成果执行此操作，以便我们可以查看一组库和可执行文件中的版本是否与关联清单中的列表匹配。

HTH。

欢呼声，

罗布

Answer 6

Subversion处理二进制文件非常好，非常快，并且可编写脚本。 VisualSVN和TortoiseSVN也很容易处理Subversion。

您可以设置一个从Subversion签出的文件夹，包含所有二进制文件（所有开发人员都可以推送和更新），然后在命令行输入“svn update”，或者使用TortoiseSVN：右键单击文件夹，单击“SVN更新”，它将更新所有文件并告诉您更改的内容。