【问题标题】:What is the value of atomic commits in Subversion?Subversion 中原子提交的价值是什么?
【发布时间】:2010-12-08 19:51:22
【问题描述】:

我正在尝试创建和遵循版本控制的最佳实践,并在 Subversion 中遇到了对原子提交的引用。由于我从未听说过此操作,因此我对此有一些疑问。

  • 它的目的是什么?
  • 什么时候应该使用它?
  • 它与普通提交有何不同?
  • TortoiseSVN 用户可以使用它吗?如果有,怎么做?

【问题讨论】:

  • 认为自己很幸运,因为不必使用 CVS!
  • 我想知道最佳实践是否都表明尽管提交本身总是原子的,但提交的原因可能不是“原子的”。例如,这些准则可能是: 确保构建在提交之前不会中断。每个错误修复发布一个提交。这个想法是在需要回滚时尽量减少痛苦。

标签: svn tortoisesvn commit atomic


【解决方案1】:

对于原子提交没有特殊的命令。 Subversion 中的每个提交都是原子的。

这意味着每次提交(任意数量的文件)要么成功要么失败。
不可能只有一些已提交的文件进入存储库而其他文件没有(例如,由于在提交操作的中间发生错误或其中一个文件发生冲突)。

TortoiseSVN 也是如此,因为它建立在“正常”的 Subversion 功能之上。


以下是Subversion book的摘录:

一个 svn 提交操作发布 更改任意数量的文件和 目录作为单个原子 交易。在您的工作副本中,您 可以更改文件的内容;创建, 删除、重命名和复制文件和 目录;然后提交一个 完整的更改集作为一个原子 交易。

通过原子事务,我们的意思很简单 这:要么所有的变化都发生 在存储库中,或者没有 发生。 Subversion 试图保留 面对程序的这种原子性 崩溃,系统崩溃,网络 问题和其他用户的操作。

【讨论】:

【解决方案2】:

这个想法很简单,一个文件的更改通常与另一个文件的更改相关。一些较旧的版本控制系统并没有真正在一次提交中处理多个文件(如您所说的“原子提交”),或者它们做得很差。

您不必为此做任何特别的事情。这就是 Subversion 的工作原理。但是使用 Subversion,您可以选择一次签入一个文件,或者一次签入所有修改过的文件,或者介于两者之间。

将多个文件作为一个提交执行的想法是——一般来说——您应该能够检查任何特定版本的存储库,并且它至少可以编译并有望运行。这在团队中很重要。现在在实践中,这可能不是 100% 正确,但指导原则是正确的。

因此,无论您是只做一个文件,一次完成所有更改,还是在您签入的内容之间进行一些更改,都应该作为一次提交有意义。就像您修复了一个错误并需要修改 8 个文件一样,将所有这 8 个文件作为一个提交签入,并附上一条消息,说明您修复了哪些错误以及如何修复它。如果有问题,以后推出会更容易。

【讨论】:

  • 我在我的产品组中被困在 CVS 上,所以我知道痛苦。我最希望我们拥有的一件事是“文件集提交”,或者如此处所述,原子提交。
【解决方案3】:

本例中的“原子”指的是原子操作。你可以在这里找到一个很好的定义: http://en.wikipedia.org/wiki/Atomic_operation

SVN 中的所有提交都是自动原子的,因此您在任何地方都可以免费获得它。

【讨论】:

    【解决方案4】:

    如果您想知道原子提交的好处,请想象您将一个分支合并到磁盘上的主干中。你从早上开始,午餐后你完成了,一切都编译好了,所有的单元测试都成功运行了。然后,您提交在该合并期间更改的 200 多个文件。

    在 SVN 中,要么提交成功并且一次性提交所有 200 多个文件,要么提交失败并且根本没有对存储库进行任何更改。 (关于这一点没有更多可说的。这就是它一直应该是的方式。)

    在没有原子提交的 CVS 中,您的提交可能会在 150 个文件后被中断,因为有人绊倒了您的网络电缆,剩余的 50 多个文件未提交,使存储库处于中间状态.当您尝试插入网络电缆时,团队中的其他人会签入另一组更改。这组更改与您已经签入的更改不相交,因此其他人的提交成功。但是,这些更改是不兼容的。现在,团队被困在一个存储库中,其中包含甚至无法编译的代码,更不用说通过任何测试了。更糟糕的是:你们两个有一个团队经理在你的脖子上呼吸,以尽快修复那些不兼容的变化,这样团队的其他成员就可以停止玩 Quake 并重新开始工作。

    令人惊讶的是,这种情况并不像看起来那么不可能。我去过那里好几次,得到了我收集的糟糕的衬衫。

    【讨论】:

      【解决方案5】:

      要了解原子提交的真正用途,请阅读关于持续集成的以下内容:

      http://en.wikipedia.org/wiki/Continuous_integration

      使用实际上是为了确保您可以在出现集成问题时撤消特定开发人员的所有更改。这是一个非常强大的功能,可以保持存储库中代码的完整性。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-06-07
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-11-29
        相关资源
        最近更新 更多