当前用户提交的文件称为 NF，SVN 最新版的文件称为 HF。
文件名比对
首先比对文件名，如果文件名不同，则比对文件属性的元数据，文件 ID 是相同的，说明属于同一个文件，则比对文件名称的版本号，发现 NF 文件名的版本号为 Undefined，说明 NF 文件修改了文件名，于是从本地的缓存库中获取 NF 文件旧名称的版本号与 HF 文件的名称的版本号比对，发现相同或者 NF 文件旧名称的版本号更大，则保留 NF 文件的文件名；若 NF 文件旧名称的版本号比 HF 名称的版本号小，说明什么问题？说明 HF 文件也曾修改了文件名并且提交了更新；其二当前用户没有更新最新版的数据，而是在旧版本基础上进行更新和提交。所以现在冲突就产生了，保留谁的文件名，两位提交者相互协商后手动解决冲突了。
文件名不同，比对文件属性的元数据，发现文件 ID 也不同，说明不属于同一个文件，而是新增的文件，此时 SVN 会在本地的缓存库中追溯版本数据（本地会缓存文件的各种历史版本），试图寻找到 HF 文件的相关数据，结果找到了，发现原来的文件被删除了，于是会比对被删除文件的版本和 HF 文件的版本，如果被删除文件的版本大于等于 HF 的版本号，则遵从提交的数据包，不再保留 HF 文件；如果被删除文件的版本号小于 HF 文件的版本号，说明两个问题，其一 HF 文件是后来有人更新后提交的；其二当前用户没有更新最新版的数据，而是在旧版本基础上进行更新和提交。因此这样的删除行为 SVN 服务器是不会直接通过的，所以冲突产生了。被删除的文件是否保留，两位提交者相互协商后手动解决冲突了。
如果 SVN 在追溯版本数据的时候没有找到 HF 文件相关的数据，则说明当前用户提交的是新增数据，于是保留 NF 和 HF 两份文件到 HEAD 片段中，而原来的 HF 文件会被归档到旧版本片段中。此时其他用户从 SVN 检出或导出或更新就会得到两份文件了。
如果 NF 和 HF 的文件名相同但是文件 ID 不同，也就是说实际是两个不同的文件，但是取名相同（例如，当前用户下载了 HF 文件，后来删除了，又重新创建了一份同名的文件），文件系统是不允许同个目录下存在两份同名的文件的，所以此时 SVN 也是在本地的缓存库中追溯版本数据，如果发现当前用户删除了与 HF 同 ID 的文件，而且版本相同，则 SVN 会遵从当前用户的提交只保留当前用户的提交的文件；如果当前用户删除的与 HF 同 ID 的文件版本更小，则 SVN 不会直接通过，所以冲突产生了。保留哪个文件，两位提交者相互协商后手动解决冲突。
文本行比对
如果文件名和 ID 都相同的情况下，则逐行比对文件内容。
NF的第1行与HF的第1行比对，先比对内容，内容相同则NF的第1行内容保留下来，内容不同则比对行的版本号，如果NF的第1行的版本号是 Undefined，则追溯该行的旧版本数据，如果发现NF文件的第1行的旧版本号等于HF文件的第1行的版本号，则保留NF第1行的数据，如果NF文件的第1行的旧版本号小于HF文件的第1行的版本号，则产生冲突，需要手动解决。所以基于这样的逻辑，多人同时修改同一位置的数据最先提交的数据顺利通过，但是后面提交的数据都会产生冲突，因为从本地缓存库中提取到的版本数据肯定被 SVN 服务器 HEAD 片段的数据的版本小。这里说的 HEAD 片段其实就是所谓的“集中式版本库”，SVN 用户都是从这个版本库中下载最新版本的数据资源。
NF的第1行与HF的第1行比对，内容不同，则比对版本号，如果可以直接取到 NF 文件第 1 行的版本号，则说明 NF 文件的第 1 行没有修改过，如果版本号相同，则直接保留 NF 的第1行文本内容，如果NF文件的第1行的版本号低于HF文件的第1行的版本号，这说明当前用户在提交的时候没有更新最新版的数据直接提交了，但是没有关系，SVN 知道 NF 文件中的第 1行文本是旧数据，所以会保留 HF 文件的第1行数据。
按上述的逻辑比对后面的所有文本行…
——
这样的理解对吗？
