将代码和数据保存在单独的存储库中的优缺点

Question

我们有一个项目，其中包含数据和代码，捆绑到一个Mercurial存储库中。数据与代码一样重要（它包含业务逻辑的参数，一些输入等）但是，数据文件的格式很少变化，并且很自然地独立于代码更改数据文件。

统一存储库的一个优点是我们不必跟踪多个修订：如果我们需要重新创建先前运行的输出，我们只需要将系统更新为存储在输出日志。

一个缺点是，如果我们在多个磁头处于活动状态时修改数据，我们可能会丢失数据更改，除非我们手动将这些更改复制到每个磁头。

将代码和数据拆分为单独的存储库还有其他优缺点吗？

Answer 1

多次回购：

• <强>优点：

  • component-based approach （您可以识别可以彼此独立发展的文件组）
  • 配置规范：列出系统工作所需的引用（此处为“修订版”）。如果要修改一个部件而不更改另一个部件，则更新该列表。
  • 部分克隆：如果您不需要所有组件，则只能克隆您想要的组件（在您的情况下不适用）

• <强>缺点

  • 配置管理：您需要跟踪该配置（通常通过父仓库，注册subrepos）
  • 在您的情况下，数据完全依赖于某些版本的项目（您可以获得对项目的旧版本没有意义的新数据）

---

一个回购

• 的优点
  • system-based approach ：您将模块视为一个系统（项目和数据）。
  • repo management：all in one
  • 模块之间的紧密联系（对数据有意义）
• 的缺点
  • 数据传播（如你所述，当几个HEAD处于活动状态时）
  • 中间修订版（不反映新功能，只是因为某些数据发生了变化）
  • 较大的克隆（此处不相关，除非您的数据包含大型二进制文件）

对于非二进制数据，如果不经常更改，我仍会将它们保存在同一个仓库中。

Answer 2

是的，您应该分开代码和数据。将代码保存在版本控制中，并将数据保存在数据库中。

我喜欢版本控制，因为我是一名程序员，因为我已经十多年了，我喜欢这份工作。

但在过去的几个月里，我意识到：数据不能在版本控制中。有时候熟悉git（或其他版本控制系统）的人很难“放手”。

您需要一个支持数据库架构迁移的良好ORM。迁移（schemamigrations和datamigrations）保留在版本控制中，但数据不是。

我知道您的问题是关于使用一个或两个存储库，但也许我的答案可以帮助您获得不同的观点。