在这种情况下，svn更新的流程是什么？

Question

好的，我知道这个命令有效，但我有一个愚蠢的问题，我一直无法回答。

假设我有一个svn存储库，其中包含一个名为a.txt的文件，并且它有一个数字，例如X，用户A检查出来，然后在a.txt中将其更改为Y，现在他想提交它，所以在做之前他做了SVN更新，所以理想情况下应该发生的是SVN更新应该引发冲突，因为这两个文件都不同。但在我的情况下，SVN更新运行并且说存储库和工作副本之间没有当前的更改。

谁能告诉我，我的推理是正确的？在我看来，这种情况与两个用户之间的标准svn冲突完全相似

编辑： 看看sharptooth的答案，显然我的推理是不正确的，所以有人可以提供svn更新的流程概述吗？即如果我有R repo和W工作副本，那么在计算diff时svn update会查找什么？

Answer 1

在SVN中，“checkout”是仅客户端操作，工作副本更改也是仅客户端操作，存储库从不知道它们。由于没有人更改文件的存储库副本，因此没有理由发生冲突。如果某个用户B在用户A上次更新（或签出）文件的那一刻与用户A执行相关更新的那一刻之间提交了对同一文件的更改，则会发生冲突。

Answer 2

您的本地工作副本包含当前版本的原始状态的所有文件。这些原始文件存储在.svn文件夹中。 .svn文件夹的大小实质上等于项目文件的大小。当您发布更新时，SVN客户端会将此.svn文件夹更新为最新版本，然后尝试更新所有工作文件。如果某个文件被更改，那么它将尝试合并工作文件中的更改。如果它不能合并，它会抱怨冲突。如果新版本和工作文件都更改了文件中的同一行，则会发生这种情况。然后，您必须解决冲突，记住旧的，从存储库到达的新内容以及您自己的更改。

一旦发出提交，SVN客户端首先检查您的工作副本是否具有最新版本，以及是否已将工作文件与.svn文件夹中的文件之间的所有差异发送到服务器。如果一切顺利，那么它会将所有不同的工作文件复制到.svn文件夹中，因此.svn文件夹与服务器上的存储库同步。

Answer 3

'svn update'没有显示冲突，因为首先它让用户默认覆盖其本地更改。这意味着当某个其他用户在您在本地更改文件的同一位置提交了不同的内容时，它会发生冲突，否则将不会发现冲突。也许您很清楚，即使在更新后也可以通过运行'svn diff'来查看更改。