SVN实际应用中的注意事项

<?phpecho 'SVN实际应用中的注意事项来源:极客头条一. 提交之前先更新1.SVN更新的原则是要随时更新,随时提交.当完成了一个小功能,能够通过编译并且自己测试之后,谨慎地提交. 2.如果在修改的期间别人也更改了svn的对应文件,那么commit就可能会失败.如果别人和自己更改的是同一个文件,那么update时会自动进行合并,如果修改的是同一行,那么合并时会产生冲突,这种情况就需要同之前的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突之后,程序不会影响其他功能. 3.在更新时注意所更新文件的列表,如果提交过程中产生了更新,则也是需要重新编译并且完成自己的一些必要测试,再进行提交.这样既能了解别人修改了哪些文件,同时也能避免SVN合并错误导致代码有错.二. 保持原子性的提交每次提交的间歇尽可能地短,以几个小时的开发工作为宜.例如在更改UI界面的时候,可以每完成一个UI界面的修改或者设计,就提交一次.在开发功能模块的时候,可以每完成一个小细节功能的测试,就提交一次,在修改bug的时候,每修改掉一个bug并且确认修改了这个bug,也就提交一次.我们提倡多提交,也就能多为代码添加上保险.三. 提交时注意不要提交本地自动生成的文件一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交(例如eclipse中的.>四. 不要提交不能通过编译的代码代码在提交之前,首先要确认自己能够在本地编译.如果在代码中使用了第三方类库,要考虑到项目组成员中有些成员可能没有安装相应的第三方类库.项目经理在准备项目工作区域的时候,需要考虑到这样的情况,确保开发小组成员在签出代码之后能够在统一的环境中进行编译.五. 不要提交自己不明白的代码代码在提交入SVN之后,你的代码将被项目成员所分享.如果提交了你不明白的代码,你看不懂,别人也看不懂,如果在以后出现了问题将会成为项目质量的隐患.因此在引入任何第三方代码之前,确保你对这个代码有一个很清晰的了解.六. 提前协调好项目组成员的工作计划项目经理应该合理分配工作计划.每个成员在准备开始进行某项功能的修改之前,如果有可能,先跟工作小组的成员谈谈自己的修改计划,让大家都能了解你的思想,了解你即将对软件作出的修改,这样能尽可能的减少在开发过程中可能出现的冲突,提高开发效率.同时你也能够在和成员的交流中发现自己之前设计的不足,完善你的设计.七. 对提交的信息采用明晰的标注在一个项目组中使用SVN,如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈,项目经理无法很清晰的掌握工作进度,无法清晰的把握此次提交的概要信息.在发现错误后也无法准确的定位引起错误的文件.所以,在提交工作时,要填写明晰的标注,能够概要的描述所提交文件的信息,让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改.八. 慎用锁定功能在项目中要慎用锁定的功能,在你锁定了一个文件之后别人就无法继续修改提交该文件,虽然可以减少冲突的发生率,但是可能会影响项目组中其他人员的工作.平时只有在编辑那些无法合并的文件(例如图片文件,flash文件等)时,才适当的采用锁定操作.九: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(解决)提交解决冲突后的文件.即使是一小步也想与你分享立即下载';