一、提交冲突
默认规则:提交代码前,先更新.查看是否有版本冲突,解决后在提交.
1.1 演示版本冲突
- 用户A修改文件并提交 (成功)
- 用户B修改文件并 提交 (失败)
1.2 解决提交冲突问题
- 1 获取客户B服务器最新版本
- 同时,针对版本不统一的文件信息,会生成对应的文件,供用户查看.
带有黄色惊叹号的文件表示当前文件与SVN服务器中的文件冲突,并已将冲突内容进行了合并.需要用户手工修改.
.mine后缀的文件是用户在更新之前的最后修改版本内容,可通过原始编辑器查看.
.r*后缀的文件是当前文件对应的各个版本的文件内容,r后面的数字是版本号,可通过原始编辑器查看.
- 2 查看并修改冲突文件
- 打开原始文件,其中包含有冲突内容,用户根据需要进行调整.
- 修改后
- 3 删除冲突备份信息,并进行提交
- 将除冲突文件之外所生成的所有文件进行删除,并对原始文件进行合并冲突处理后,原始文件状态由冲突状态转换为已编辑状态.此时即可正常提交.
- 将除冲突文件之外所生成的所有文件进行删除,并对原始文件进行合并冲突处理后,原始文件状态由冲突状态转换为已编辑状态.此时即可正常提交.
二、锁机制
2.1 锁(不推荐)
- 为避免提交冲突,可以为任何一个加入版本控制的资源提供锁.避免多用户同时操作同一文件引发冲突.由于文件锁定后,只能由一个用户操作,实际开发中没有实用性.
2.2 加锁
- 获取锁
- 锁定完成
- 获取锁后,显示当前被文件被锁定,其他人无法进行操作
- 客户B在用户A没有释放锁的情况下 提交文件会失败(类似于JavaEE的乐观锁)
- 客户A提交文件后锁自动释放
2.3 破解锁(需要权限)
- 如果客户A恶意锁定文件,其他人可以破解锁
- 打开版本浏览器
- 查看锁定文件
- 选择锁文件 --> 右键 --> 解锁