文章目录
前言
最近有朋友在工作时遇到了一个关于SVN的小坑，他解决后分享了我，我所在的公司虽然不用SVN，但是也给了我一个警惕，所以我在网络上收集了一些关于SVN的注意事项，并记录下来，以备我以后使用
注意事项
1.保持原子性提交
每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。
2. 提交之前先更新
1.SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。 2.如果在修改的期间别人也更改了svn的对应文件，那么commit就可能会失败。如果别人和自己更改的是同一个文件，那么update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。 3.在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。
3.提交时尽量提交自己负责的文件
这样能避免更新失败的问题
4.提前协调好项目组成员的工作计划
项目经理应该合理分配工作计划。每个成员在准备开始进行某项功能的修改之前，如果有可能，先跟工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。
5.对提交的信息打好清晰的注解
在一个项目组中使用SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。
6.慎用锁定功能
在项目中要慎用锁定的功能，在你锁定了一个文件之后别人就无法继续修改提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件（例如图片文件，flash文件等）时，才适当的采用锁定操作。
7.SVN版本冲突解决详解
A用户修改文件，添加内容“A用户修改内容”完成后提交到服务器, B用户修改同一个文件，添加内容“B用户修改内容”完成后提交到服务器。B用户将文件提交至服务器时，提示版本过期：首先应该从版本库更新版本，然后去解决冲突，冲突解决后要执行svn resolved（解决），然后在签入到版本库。在冲突解决之后，需要使用svn resolved（解决）来告诉subversion冲突解决，这样才能提交更新。
解决冲突有三种选择：
A、放弃自己的更新，使用SVN revert（回滚），然后提交。在这种方式下不需要使用SVN resolved（解决）。
B、放弃自己的更新，使用别人的更新。使用最新获取的版本覆盖目标文件，执行resolved filename并提交(选择文件—右键—解决)。
C、手动解决：冲突发生时，通过和其他用户沟通之后，手动更新目标文件。然后执行resolved filename来解除冲突，最后提交。
解决步骤：update出现冲突
在冲突的文件上（选中文件–右键菜单—TortoiseSVN—Edit conflicts（解决冲突））,出现三个窗口Theirs（服务器最新版本）、Mine（本地修改后的版本）、Merged（合并后的文件内容显示）
如果需要使用哪个版本，则在窗口上右键，选择Use this textblock（使用这段文本块）
修改完成后，保存文件
在B用户的冲突目录下，选中文件–右键菜单—TortoiseSVN—Resolved（解决）
提交解决冲突后的文件。
总结
以上就是我收集到的一些关于SVN的注意事项，以备我以后使用以及分享给大家！