2023年6月30日发(作者：)

SVN版本控制的数据合并规则⽂章⽬录⾃⼰的猜想假设当前⽤户提交的⽂件称为 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 ⾏与 H F的第 1 ⾏⽐对，内容不同，则⽐对版本号，如果可以直接取到 NF ⽂件第 1 ⾏的版本号，则说明 NF ⽂件的第 1 ⾏没有修改过，如果版本号相同，则直接保留 NF 的第1⾏⽂本内容，如果 NF ⽂件的第 1 ⾏的版本号低于 HF ⽂件的第 1 ⾏的版本号，这说明当前⽤户在提交的时候没有更新最新版的数据直接提交了，但是没有关系，SVN 知道 NF ⽂件中的第 1 ⾏⽂本是旧数据，所以会保留HF ⽂件的第 1 ⾏数据。按上述的逻辑⽐对后⾯的所有⽂本⾏…事实是什么在提交的时候，SVN 并不是按以上的逻辑和规则来⽐对数据，中央版本库中原来的数据会移⼊历史版本池中，然后备份⼀份到

head 分区中（即主分⽀

/trunk），接着简单判断同名⽂件内容是否⼀致，⼀致则保留 head 的数据，否则被新提交的⽂件替换掉。在客户端版本库的缓存数据中，有保存客户端版本库的⽂件的实际路径与 SVN 服务端版本库中的对应路径的映射关系。只要有修改客户端版本库中的数据，都会把被修改⽂件的客户端路径和相对应的 SVN 服务端版本库的路径写⼊到提交计划中。所谓

versioned 就是每个客户端版本库的⽂件都在这个路径映射表中，如果你改了客户端版本库中的⽂件名或者删除了，SVN 客户端就⽆法找到对应的映射关系，就会提⽰⽂件丢失、⽆法识别等。提交计划客户端版本库的⽂件只要修改了内容，或者通过命令

svn add 添加的⽂件，相关⽂件的路径都会写⼊提交计划中（schedule）提交数据1. 只要客户端版本库的版本号和服务端版本库的版本号不同，就⽆法正常提交，提⽰“过期”2. 如果提交数据成功，是将⼯作副本的数据完全覆盖服务端的数据，没有进⼊⽂件内容进⾏⽂本⾏的数据⽐对更新客户端版本库数据时，同名⽂件中⽂本⾏的数据⽐对规则内容对⽐不相同相同相同相同不相同不相同不相同相同相同不相同客户端标记状态删除删除未修改过修改过修改过修改过未修改过未修改过修改过修改过服务端标记状态修改过未修改过未修改过修改过未修改过修改过版本不同删除删除删除内容处理⽅案产⽣冲突遵从客户端的遵从客户端的遵从客户端的遵从客户端的产⽣冲突遵从服务端的遵从服务端的产⽣冲突产⽣冲突注：服务端⽂本是否修改过，是针对客户端⽂本⾏的版本⽽⾔。