Version control 开发代码的多个实例的版本控制

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

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

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

类似地，随着我们添加新功能，内部代码总是在不断演变。其中许多应该合并到主干中，以便将来的应用程序可以使用它们。然而，也有相当多的案例特定的黑客，主干不需要看到

---

我们应该如何组织这场混乱？显然，越简单越好。

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

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

分支用于开发工作，这些“输入文件、运行时文件和后处理文件”将以自己的速度发展

对于此类文件，我们在VCS中管理的是：

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

---

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

利用版本控制和问题跟踪，将问题与代码提交联系起来，极大地提高了生产效率

关于存储库结构，至少看看subversion，该工具只是有一些约定，但没有严格的规则。让一个名为“trunk”的树来管理所有的“公共代码”怎么样

---

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

你会建议三棵独立的树吗？源文件树、模板和脚本树以及项目树（我猜是一组标记）包含源文件和配置文件的大小写特定版本？@weymouth:不，源、模板和脚本可以位于同一棵树中，因为它们链接在一起。您有一棵树和一个数据库。对于给定的树版本，您需要约定从数据库中获取正确的值。