svn资料整理很不错.docx

svn资料整理很不错.docx

《svn资料整理很不错.docx》由会员分享，可在线阅读，更多相关《svn资料整理很不错.docx（10页珍藏版）》请在冰豆网上搜索。

svn资料整理很不错

1.svn操作流程

开发人员使用svn进行开发的一般流程是：

·checkout（检出）项目

·更新文件或目录——>update

·修改文件或目录——commit（提交）变更

·增加文件或目录——>add（增加）文件或目录——>commit（提交）

·删除文件或目录——>commit（提交）上一级目录

其中，checkout只进行一次，以后使用update更新即可。

update、commit、add操作根据需要经常使用。

现在你已经从Subversion版本库中检出了一份工作复本，·一个新检出的工作复本使用绿色的对勾做重载。

表示Subversion状态正常.

·在你开始编辑一个文件后，状态就变成了已修改，而图标重载变成了红色感叹号。

通过这种方式，你可以很容易地看出哪些文件从你上次更新工作复本后被修改过，需要被提交。

·如果在提交的过程中出现了冲突图标变成黄色感叹号。

·打叉的图标表示当前文件夹下的某些文件或文件夹已经被计划从版本控制中删除，或是该文件夹下某个受控的文件丢失了。

·加号告诉你有一个文件或是目录已经被计划加入版本控制。

2.操作详解

lcommit（提交）操作

把本地目录中变化了的文件或目录提交到版本库中，用commit操作。

增加新文件或目录，要先用add，再commit。

删除文件或目录，commit上一级目录。

在资源管理器中，选择本地目录或文件，鼠标右键菜单选择”SVNCommit”。

建议写版本号或变更原因，以便将来查找。

下框列出提交的内容。

没有可提交的内容，下框中会显示一段说明文字。

点“ok”。

提交结束，显示结果。

点“ok”。

3、解决代码冲突

如果commit时出现“Youhavetoupdateyourworkcopyfirst.”红色警告，说明版本库中的此文件已经被其他人修改了。

请先点“ok”按钮退出。

执行update,然后再commit。

如果修改与update得到的代码不冲突，则自动合并。

如果冲突（比如对同一行代码进行了修改），则出现”Oneormorefilesareinaconflictedstate.“红色警告，并产生几个文件记录冲突。

一般情况下，我们不要直接编辑冲突文件。

而按照以下操作手工解决冲突。

在资源管理器中，选择commit时冲突的那个文件，鼠标右键菜单选择”Editconficts”。

出现界面，分为”Theirs”、”Mine”和”Merged”3部分，表示”别人修改的内容”、”我修改的内容”和”合并后的结果”3部分。

我们是要将”别人修改的内容”和”我修改的内容”有取舍地合并起来，形成”合并后的结果”。

合并一般分为4种情况：

保留”我的修改”,舍弃”别人的修改”。

鼠标右键点击Mine框的相应行，点击”Usethistextblock”。

舍弃”我的修改”,保留”别人的修改”。

鼠标右键点击Theirs框的相应行，点击”Usethistextblock”。

同时保留”我的修改”和”别人的修改”，并将”我的修改”放在前面。

鼠标右键点击Mine框的相应行，点击”Usetextblockfromminebeforetheirs”。

同时保留”我的修改”和”别人的修改”，并将”别人的修改”放在前面。

鼠标右键点击Mine框的相应行，点击”Usetextblockfromtheirsbeforemine”。

合并完成，Ctrl+S存盘，退出。

然后，在资源管理器中，选择冲突文件，鼠标右键菜单选择”Resolved”,标记冲突已解决。

系统会自动删除因冲突而新建的文件。

此时，就可以继续进行commit操作了。

举例说明冲突：

协同开发中svn使用规范

1、使用自己的账户和密码

各员工需牢记各自的账户和密码，不得向他人透漏，严禁使用他人账户进行SVN各项操作。

2、不要签出（SVNCheckout）整个目录。

工作中需要对项目或解决方案进行任何操作时，应使用SVN请求最新代码或文件。

不要签出（SVNCheckout）整个目录，除非特别必要，不应同时签出过多的项。

3、先更新（SVNUpdate），再提交（SVNCommit）

SVN更新的原则是要随时更新（SVNUpdate），随时提交（SVNCommit）。

当完成了一个小功能，能够编译并且通过自己测试之后，谨慎地提交。

如果在修改的期间别人也更改了SVN的对应文件，那么Commit就可能会失败。

如果别人和自己更改的是同一个文件，那么Update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。

在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。

这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。

4、多提交（SVNCommit），不要长时间签出（SVNCheckout）项目或解决方案，减少因多人对同一文件进行操作而产生的文件冲突。

每次提交的间歇尽可能地短，以几个小时的开发工作为宜。

例如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。

在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。

我们提倡多提交，也就能多为代码添加上保险。

5、不要提交不能通过编译的代码

代码在提交之前，首先要确认自己能够在本地编译。

如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。

项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出（SVNCheckout）代码之后能够在统一的环境中进行编译。

6、每次提交必须书写明晰的标注

在一个项目组中使用SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。

在发现错误后也无法准确的定位引起错误的文件。

所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。

7、提交时注意不要提交本地自动生成的文件

例如eclipse中的.classpath文件，Windows生成的缩略图Thumbs.db，项目编译生成的临时文件.obj,.class等等。

如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。

提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。

8、不要提交自己不明白的代码

代码在提交入SVN之后，你的代码将被项目成员所分享。

如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。

因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。

9、慎用锁定功能

在项目中要慎用锁定的功能，在你锁定了一个文件之后别人就无法继续修改提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。

平时只有在编辑那些无法合并的文件（例如图片文件，flash文件等）时，才适当的采用锁定操作。

10、标记版本

对已经成熟稳定的版本，可标记为“发布版”，由项目经理提交给管理员。

管理员将该版本向技术支持部成员开放，用于新项目的实施和现有用户的升级维护。

11、管理员需对SVN管理的所有项目定期备份。

12、.svn隐藏目录

版本管理工具可以管理任何类型的文件，但是在软件开发过程中哪些应该纳入版本管理，哪些不应该纳入版本管理，还是有些建议需要遵循。

1.所有源代码、makefile文件、工程文件需要入软件库。

2.所有编译过程中生成的中间文件和目标文件一般不需要加入到版本库。

3.构建脚本、测试脚本、说明文件、安装脚本、设计文档等需要加入到版本库。

4.工程中的用到的图标文件、声音文件等在编译、运行时需要的文件要加入到版本库中。

5.第三方源代码、库等开发、运行环境需要加入到版本库。

6.版本库要合理组织目录，以满足项目的需求。

7.避免在版本库中多处保存同样的东西，如果确实有此需求，可以在一处保存，用一个项目级的工作区初始化脚本来实现