2

我在工程实验室工作，而不是计算机科学实验室。因此，我们的内部软件不是可交付的产品。相反，内部软件用于分析工程问题，然后我们提供结果。

这使得版本控制成为一个活生生的地狱。或者也许我应该说标准的“主干和分支”版本控制树结构似乎并不适用。我希望有人可以提出更好的做事方式。

例如，每个工程项目都需要添加特定案例的输入文件、运行时文件和后处理文件。这些都不属于trunk，因为它们不是通用的，但是每个新项目都需要这些文件。我们尝试将模板放在主干中，但没有明确的最佳实践来确定何时应该合并模板。

同样，随着我们添加新功能，内部代码总是在不断发展。其中许多应该合并到主干中，以便它们可用于未来的应用程序。但是，也有很多特定于案例的 hack，trunk 不需要查看。

我们应该如何组织这个烂摊子？显然，越简单越好。

4

2 回答 2

1

我们真的努力让我们的项目保持独立：

  • 源文件（在您选择的任何 VCS 中管理，例如 SVN）
  • 配置文件（特定于团队或环境）

分支用于开发工作，那些“输入文件、运行时文件和后处理文件”将按照自己的节奏发展。

对于那种文件，我们在 VCS 中管理的是：

  • 模板
  • 脚本能够采用该模板并生成（私有，如未版本化的）配置文件，其中包含正确的值。
    这些值来自另一个引用，例如数据库，团队（或环境管理员）可以随意更新它们，而不用担心签出/签入/合并。
    然后，如果需要，可以在其自己的 VCS 中对该数据库进行版本控制（例如，参见这个SO 问题，或者，作为替代方案，那个）
于 2010-11-04T10:04:59.510 回答
0

在工程中，版本控制经常被低估，而为了重复实验，必须恢复给定的设置。对于易于使用的一般采用，主要面向 GUI，工具有很大帮助。

利用将问题与代码提交相关联的问题跟踪的版本控制极大地提高了生产力。

关于存储库结构，至少从颠覆来看，只有约定，但没有工具强加的严格规则。如果有一个名为“主干”的树来管理所有“公共代码”呢？

对于每个工程任务，都会创建一个分支。这只不过是一个带有版本控制的“项目文件夹”。与其他项目相关的源代码将合并回主干。

于 2010-11-04T21:41:34.000 回答