将更多文件作为预提交挂钩提交是否安全？

Question

我想在Subversion中将文件从一个分支复制到另一个分支时自动提交数据库。使用svn commmit作为预提交钩子的一部分是否安全，假设我们在非常特殊的情况下这样做？

Answer 1

即使它是安全的，也可能没有你期望的效果。

当您处于预先提交状态时，新事务已经创建，但尚未提交。您可以访问该信息来完成工作，但是额外的svn commit会创建一个也未提交的单独事务。

新交易不会在当前交易中看到任何变化，因为尚未最终确定。

您可能需要运行一些自定义脚本来为您执行此操作，可能是构建系统的一部分。

此外，您需要一个工作副本来提交，您没有在服务器上运行pre-commit挂钩的地方。您可能能够使用共享工作副本拼凑一些东西，并希望没有两个人同时运行pre-commit挂钩，但同样，您可能最好使用自定义脚本解决方案。

Answer 2

提交本身在SVN中是安全的。如果您的版本在提交时已过时，则操作将被拒绝。当然，在SVN中提交二进制文件使你不可能做一些基于svn的冲突解决，这很难过......

你应该担心的是svn update。你说你想在SVN中存储数据库。当用户使用他们的数据文件时，我也不知道MySQL，Oracle和MS-SQL都不喜欢它......你可以这样做，但数据库配置文件也应该存储在SVN中。也许日志也是如此。当然 - 执行更新时不应运行RDBMS。相当多的大惊小怪，不是吗？

您还可以使用SVN命令锁定文件以禁止其他用户修改。

考虑到所有这些 - 也许还有其他更适合您的解决方案，而不是将二进制数据库文件存储在面向文本的版本控制系统中？

Answer 3

这听起来像是一个可疑的命题 - 无论您使用哪种VCS（版本控制系统）。与往常一样，详细地说，“它取决于”。

第一个问题是“提交数据库”是什么意思？据推测，您正在考虑存储在单个文件中的数据库，并且您将文件简单地提交为二进制数据块。这假设没有其他人在使用数据库。主DBMS提供了用于确保数据库连贯备份的工具，即使它当时正在使用。如果您的DBMS正在运行服务器，如果您安静地让VCS办理登机手续，可能会感到非常不满意。典型的VCS将删除当前提取的文件并将其替换为新版本（例如，如果要在其中展开关键字）。您必须确保不在DBMS文件中展开关键字。当数据库增长并占用多个空间时会发生什么？

我更倾向于确保有数据库备份，然后是版本控制。但这很大程度上取决于您的DBMS在备份设施（以及恢复设施）方面提供的内容 - 我假设其目的是能够在需要时恢复数据库。

最后，对于大多数系统来说，数据库的内容并不是特别重要;重要的往往是数据的模式 - 表，列，索引，约束，存储过程，视图，权限......实际数据行通常具有最小的重要性。

Answer 4

即使它是安全的，但这听起来似乎会让用户感到困惑。他们要求提交X，并且X + Y已经提交。对于那些不知道发生了什么的人来说，这是一个秘诀。特别是当您尝试添加新的团队成员时。

我还要注意，即使这个工作正常，对我来说听起来像VCS操作的边缘条件。多年来我学会了如果没有充分的理由不要将我的工具推向边缘。边缘条件是容易出现错误的地方，我担心将来会发生一些变化以打破这种情况。