SVN使用规范

    在SVN中分为主干(trunk)分支(branch)标记(tag),branch和tag在一个功能选项中,非常容易混淆。


    在实现中,branch和tag,他们默认的权限上和一般的目录没有区别。什么时候使用tag,什么时候使用branch完全是由个人根据规范和需要来选择的,并不是强制的。


    一般情况下:

    trunk:是用来做主方向开发的,一个新模块的开发,这个时候就放在trunk,当模块开发完成后,需要修改,就用branch。

    branch:是用来做并行开发的,这里的并行是指和trunk进行比较。

    tag:是用来做一个milestone的,不管是不是发布版本,但都是一个可用的版本。这里,应该是只读的。更多的是一个显示用的,给人一个可读的标记。


    比如,1.0开发完成,这个时候要做一个tag,tag_xx_1_0,然后基于这个tag做发布,比如安装程序等。trunk进入 1.1的开发,但是1.0发现了bug,那么就需要基于tag_xx_1_0做一个分支,branch_bugfix_1_0,基于这 个branch进行bug修改,等到bugfix结束,做一个tag,tag_xx_1_0_1,然后,根据需要决定 branch_bugfix_1_0是否并入主干。


    branches:分枝 
    当多个人合作,可能有这样的情况出现:A突然有个想法,跟原先的设计不太一致,可能是功能的添加或者日志格式的改进等等,总而言之,这个想法可能需 要花一段时间来完成,而这个过程中,A的一些操作可能会影响B的工作,A从现有的状态单独出一个project的话,又不能及时得到 B对已有代码做的修正,而且独立出来的话,A的尝试成功时,跟原来的合并也存在困难。这时最好的实践方法是使用branches。 A建立一个自己的branch,然后在里面实验,必要的时候从B的trunk里取得更新,或者将自己的阶段成果汇集到trunk中。

 
    trunk:主干 
    主干,一般来说就是开发的主要呆的地方。

   
    tag::标记 
    在经过了一段时间的开发后,项目到达了一个里程碑阶段,你可能想记录这一阶段的代码的状态,那么你就需要给代码打上标签。


    SVN使用的好,在合作中就会省去很多力气,也会防止出现很多不必要的BUG,对我们的工作来说,会大大提高效率,省时省力。

介绍SVN各个目录使用规范 Svn目录使用规范 TortoiseSVN客户端工具 选择创建SVN目录结构的选项(生成trunk、branches、tags目录),如下图: 1、 trunk是主分支,是日常开发进行的地方。 2、branches是分支。一些阶段性的release版本,这些版本是可以继续进行开发和维护的,则放在branches目录中。 3、tags目录一般是只读的,这里存储阶段性的发布版本,只是作为一个里程碑的版本进行存档。 注:在这需要说明下分三个目录的原因,如果项目分为一期、二期、三期等,那么一期上线时的稳定版本就应该在一期完成时将代码copy到branches上,这样二期开发的代码就对一期的代码没有影响,如新增的模块就不会部署到生产环境上。而branches上的稳定的版本就是发布到生产环境上的代码,如果用户使用的过程中发现有bug,则只要在branches上修改该bug,修改完bug后再编译branches上最新的代码发布到生产环境即可。tags的作用是将在branches上修改的bug的代码合并到trunk上时创建个版本标识 Trunk目录:Doc(文档库,放项目相关文档类)、sourcecede(代码库) Doc目录下按项目存放文档,以下以proj1为例做说明 Proj1----项目名 1、Controlled------组织级scm建一个名为controlled的目录,当项目某文档通过评审后,组织级scm从项目目录下找到那文档,复制到controlled目录下。(一般用不到) 2、Develop---开发文档 2.1、Design----设计文档 2.1.1、DbDesign---数据库设计文档 2.1.2、HLD---概要设计 2.1.3、InterfaceDesign---接口设计 2.1.4、ServiceDesign---服务设计 2.2、REQ---需求文档 2.3、SRS---软件需求规格说明 2.4、Test---测试文档 2.4.1、Review---可空 2.4.2、TestCese---测试用例 2.4.3、TestDoc---测试文档 2.4.4、TestEnv---测试环境说明 2.4.5、TestReport---测试报告 3、Document---项目文档 4、Management---管理文档 4.1、Meetings--会议纪要 4.2、PIM--- 4.3、Plan---计划 4.3.1、review 4.3.2、SDP---软件开发策划文档 4.3.3、SPP---软件项目策划文档 4.4、report---报告 4.4.1、Milestonereport---版本报告 4.4.2、ProjectTrackReport---项目跟踪报告 4..4.3、SCM---软件配置管理文档  4.4.4、SQA---软件质量保证计划 4.4.5、项目周报 4.5、Sow---工作说明书 4.6、Summarize---总结 4.7、Template---模板 4.8、Trainning---培训文档 打标签/分支有两种方式: 1、选中项目,就是trunk下的本地项目,右击,选中Branch/Tag,出现如下对话框。 下图中的配置完成了之后,点击OK即可完成“打标签/分支”。 2、直接在SVN上在对应的标签/分支目录下创建对应的版本文件夹,将trunk下稳定版本的代码直接copy到对应的文件目录下即可。
[本地工作区] :work copy ,本地工作副本; [主项目]:引用共用模块的新项目(工程) 最新版本(HEAD revision):版本库里文件或目录的最新版本 SA :SVN服务器的管理员 PRA :单个项目库的管理员,或者是项目负责人 User :普通工作人员 WC :work copy ,本地工作副本 1. 版本控制原则 SVN(或者其他版本控制软件)只是一个版本控制的辅助工具,不可能把所有的问题都自动解决掉。尤其,对于冲突这个麻烦事儿,项目成员在项目进程中要尽量通过优化流程来解决,而不是将希望寄托于软件工具来自动解决一切问题。 建议的开发过程组织: 1. 随行就市 项目刚开始阶段,单独开发;项目稳定阶段,完整开发。项目开发初期,各个项目成员负责自己的文件夹(或者模块),与SVN服务器间的更新、提交等操作只需要针对自己负责的文件夹(或者模块)就行了,他人的文件夹(或者模块)可以不必关心;项目稳定阶段,也就是每天的变更量很小了,所有项目成员与SVN服务器的更新、提交等操作需要针对项目的所有文件夹(或者模块),各个项目成员在其本地编译时本地工作区的全部项目程序(或者资料)均为最新的版本,保证项目作为整体能够顺利运行。 2. 能躲就躲 尽量保证一份文件只有一个项目成员在编辑。举例说明:程序员A负责底层中文件 DBAccess.cs的编写,如果程序员B的工作要求他为DBAccess.cs增加两个方法,程序员B应该通知程序员A来增加而不是自己增加;如果此时A非常繁忙需要B自己增加,就需要B先更新本地的DBAccess.cs,然后开始修改,修改完成后立即提交并通知A更新本地的文件,通过缩短提交间隔来减少冲突。
评论 43
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值