【问题标题】:Is it safe to commit more files as a pre-commit hook?提交更多文件作为预提交挂钩是否安全?
【发布时间】:2008-12-29 12:28:02
【问题描述】:

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

【问题讨论】:

    标签: svn


    【解决方案1】:

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

    在预提交时,新事务已创建,但尚未提交。您可以访问该信息来完成您的工作,但额外的 svn commit 会创建一个尚未提交的单独事务。

    该新交易不会看到您当前交易中的任何更改,因为它尚未最终确定。

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

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

    【讨论】:

    • 如果预提交钩子再次触发数据库备份,您可能会运行很多预提交触发器:D
    【解决方案2】:

    提交本身在 SVN 中是安全的。如果您提交时您的版本已过时,则该操作将被拒绝。当然,在 SVN 中提交二进制文件让你无法进行一些基于 svn 的冲突解决,这很可悲……

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

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

    考虑到这一切——也许还有比将二进制数据库文件存储在面向文本的版本控制系统中更适合您的解决方案?

    【讨论】:

    • 我将数据库转储到一个 sql 文件中。它不是二进制文件。
    • 好吧,“提交数据库”听起来不像“提交数据库转储”。无论如何 - 在预提交钩子中使用提交可能会导致无限递归循环,但在您的情况下,这似乎是可以避免的。祝你好运! :-)
    【解决方案3】:

    这听起来像是一个可疑的提议 - 无论您使用哪种 VCS(版本控制系统)。一如既往,详细地说,“这取决于”。

    第一个问题是“提交数据库”是什么意思?大概,您正在考虑存储在单个文件中的数据库,并且您会将文件作为二进制数据块进行简单的提交。这假设没有其他人在使用数据库。主 DBMS 提供了用于确保数据库一致备份的工具,即使它当时正在使用中。如果您的 DBMS 有一个服务器正在运行,那么如果您悄悄地让 VCS 进行签入,它可能会变得相当不高兴。典型的 VCS 将删除当前提取的文件并将其替换为新版本(例如,如果其中有要扩展的关键字)。您必须确保没有在 DBMS 文件中扩展关键字。当数据库增长并占用多个空间时会发生什么?

    我更倾向于确保有数据库备份,然后进行版本控制。但这在很大程度上取决于您的 DBMS 提供的备份设施(和恢复设施——我认为目的是能够在需要时恢复数据库)。

    最后,对于大多数系统来说,数据库的内容并不是特别重要;关键的往往是数据的架构——表、列、索引、约束、存储过程、视图、权限……实际的数据行通常意义不大。

    【讨论】:

      【解决方案4】:

      即使它是安全的,听起来也会让您的用户感到困惑。他们要求 X 承诺,X+Y 承诺。对于不知道发生了什么的人来说,这是一个秘诀。尤其是当您尝试添加新的团队成员时。

      我还想指出,即使这工作正常,对我来说这听起来像是 VCS 操作的边缘条件。多年来,我学会了不要在没有充分理由的情况下将我的工具推向边缘。边缘条件是 bug 容易出现的地方,我担心将来可能会发生一些变化以打破这种情况。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2016-10-16
        • 1970-01-01
        • 2014-12-24
        • 1970-01-01
        • 1970-01-01
        • 2012-08-23
        相关资源
        最近更新 更多