SVN 和 Visual Foxpro 数据库答案

【问题标题】：SVN and Visual Foxpro DatabasesSVN 和 Visual Foxpro 数据库
【发布时间】：2009-08-06 05:37:44
【问题描述】：

有没有人尝试在 SVN 中包含 Visual Foxpro 数据库（版本 7）？包含它的优点/缺点是什么？当存在需要包含在源代码管理中的行时，在 SCM 中处理 VFP Db 的最佳方法是什么？

【问题讨论】：

【解决方案1】：

Christof Wollenhaupt 有一个名为“TwoFox”的工具，它可以很好地将 DBC 和其他 Fox 源文件转换为 XML——描述它的文章是 http://www.foxpert.com/docs/cvs.en.htm。但是，如果您只是询问将 DBF 文件放入 SVN，您可以将它们作为二进制文件导入，并且无法在版本之间进行比较/合并，或者使用 CURSORTOXML（那是在 7 中，不是吗？）在签入之前将 DBF 转换为 XML。

【讨论】：

【解决方案2】：

虽然我没有使用过 SVN，但我已经将 VFP 与 VSS 和 Vault 一起使用。通过这两种方式，我手动将文件添加到源代码管理中，而不是尝试在开发环境中使用某种形式的集成。

基本上有两种方法可以解决这个问题：

只需手动添加 .DBC、.DCT、.DCX 以及所有 .DBF、.FPT 和 .CDX
从数据库中编写脚本以创建结构（我使用 GenDBCX 的修改版本），并通过脚本创建要保留在程序或类中的任何数据记录。

【讨论】：

【解决方案3】：

我的设置：

Windows XPsp3 作为虚拟机，运行：
- VFP 8
- TortoiseSVN
- scX to convert all of the "object files" into flat text files。

Debian 在 P4 工作站上运行：
- 通过 Apache2 的 Subverison
- 用钩子追踪到 Subversion
- Subversion 和 Trac 数据库的定期夜间备份

坦率地说，我不会检查我们拥有的数兆字节的数据库，因为仅此一项，存储库的大小就会膨胀到大约 20+ GB。我们经常有 1.6Gb 的表（以及它们的备忘录和索引），浪费时间等待 1 小时以上的 20GB 表更改提交是不值得的。相反，我们从生产系统中克隆数据并使用它来“刷新”事物，并重建我们的数据库容器以获得到表的新链接。 “刷新”过程大约每月进行一次，所用时间要少得多，通常为 40 分钟；将此与每天浪费时间进行对比。

我不需要将数据签入存储库，甚至一次。 Schema 管理已通过暂时遵循单一规则进行了简化：仅在用于生产的所有补丁都已推送到生产中后才刷新数据，这意味着两个环境的 schema 将是一致的。现在，我可以侥幸逃脱，尽管将来必须改变...

如果您只需要更改架构

如果您发现需要签入表是因为您试图捕获它们的 schema 而不一定是它们包含的数据，您可能需要查看编写一个小工具，将架构抽出到文本文件中并将其提交到 repo，而不是将厨房水槽运送到消化。

如果您绝对需要签入数据

如果表中存在对控制程序流至关重要的数据（数据即代码，而不仅仅是程序处理的数据），您可以考虑将数据修剪到所需的最低限度并签入只需将生成的存根表手动添加到存储库中即可。虽然 subversion 将处理二进制对象，但您需要将它们保持在最小大小并尽可能少地提交它们，这样您的 repo 就不会陷入困境。确保您检查了您所追求的各个表，而不仅仅是所有 *.dbf，否则当其他人试图将数 GB 的数据推送到您的存储库时，您可能会感到震惊，因为工作副本没有屏蔽所有表格。

【讨论】：