http://svnbook.red-bean.com/en/1.0/ch03s05.html
Basic Work Cycle | ||
---|---|---|
Chapter 3. Guided Tour |
http://www.open.collab.net/scdocs/ddUsingSVN_command-line.html.zh-cn
查阅了一下网络和博客园,发现还没有一个明确地指导源码管理提交准则的相关文章,因此斗胆整理了一部分自己平时开发管理的心得,加上查阅了部分英文资料写了一个不算很完善的SVN提交准则。
负责而谨慎地提交自己的代码
SVN更新的原则是要随时更新,随时提交。当完成了一个小功能,能够通过编译并且并且自己测试之后,谨慎地提交。
如果提交过程中产生了冲突,则需要同之前的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突之后,程序不会影响其他功能。
如果提交过程中产生了更新,则也是需要重新编译并且完成自己的一些必要测试,再进行提交。
保持原子性的提交
每次提交的间歇尽可能地短,以一个小时,两个小时的开发工作为宜。如在更改UI界面的时候,可以每完成一个UI界面的修改或者设计,就提交一次。在开发功能模块的时候,可以每完成一个小细节功能的测试,就提交一次,在修改bug的时候,每修改掉一个bug并且确认修改了这个bug,也就提交一次。我们提倡多提交,也就能多为代码添加上保险。
不要提交自动生成的文件
Visual Studio在生成过程中会产生很多自动文件,如.suo等配置文件,Debug,Release,Obj等编译文件,以及其他的一些自动生成,同编译代码无关的文件,这些文件在提交的时候不应该签入,如果不小心签入了,需要使用Delete命令从仓库中删除。
不要提交不能通过编译的代码
代码在提交之前,首先要确认自己能够在本地编译。如果在代码中使用了第三方类库,要考虑到项目组成员中有些成员可能没有安装相应的第三方类库或者没有放入GAC(针对.Net Framework)中,项目经理在准备项目工作区域的时候,需要考虑到这样的情况,确保开发小组成员在签出代码之后能够在统一的环境中进行编译。
不要提交自己不明白的代码
代码在提交入SVN之后,你的代码将被项目成员所分享。如果提交了你不明白的代码,你看不懂,别人也看不懂,如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前,确保你对这个代码有一个很清晰的了解。
提前宣布自己的工作计划
在自己准备开始进行某项功能的修改之前,先给工作小组的成员谈谈自己的修改计划,让大家都能了解你的思想,了解你即将对软件作出的修改,这样能尽可能的减少在开发过程中可能出现的冲突,提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足,完善你的设计。
对提交的信息采用明晰的标注
+) 表示增加了功能
*) 表示对某些功能进行了更改
-) 表示删除了文件,或者对某些功能进行了裁剪,删除,屏蔽。
b) 表示修正了具体的某个bug
1.在本机察看修改:
svn status
2.在本机下载更新本机服务器上的最新版
svn update
3.本机提交修改:
svn commit
4.提示有冲突,解决冲突(修改<<<< and >>>>>之间的内容),然后
svn resolved
别人告诉的 原文复制
当本地文件没有改动,服务器文件改动的时候,更新会从服务器取文件覆盖当前文件
当本地文件有改动,服务器文件没改动的话,不会更新此文件
当本地文件有改动,服务器文件有改动的话,如果改动的部分不冲突,就会合并文件到本地,如果有冲突的话,会提示文件冲突,需要自己手动修改以后上传到服务器
最后一个讲解合并:
服务器和本地的同一个文件(所谓同一个文件应该就是SVN相对路径相同,文件名相同的文件,这个由SVN留在本地的信息决定)已经修改,且修改的部分不重合,不重叠
当满足上面的条件的时候再更新,SVN就会自动合并
SVN的奥妙之处就在于别人提交了修改后的文件,你再提交你的话,他是不允许你提交滴。。。
>>>>
<<<
里面标记的是冲突的区域,把冲突区域删除掉为什么还不能提交
解决办法1:
删掉的话还是没有解决冲突,文件后面还会有几个文件名相同,但是后缀不同的文件
如果你不知道用SVN解决冲突的话,最简单的办法是这样的
把这个文件改名字,然后在文件所在目录更新,这样就会把服务器文件下下来,然后把自己修改的部分添加到更新的文件里面,这样就可以提交了
解决办法2:
在文件上面点击右键,到SVN的菜单,应该有编辑冲突的按钮,选择就会出现一个窗口,一边是服务器版本,一边是自己修改的版本