SVN和Tortoise基础培训.pptVIP

分支和标签 特性分支 一个特性分支是一个临时分支，用来作复杂的修改而不会干扰/trunk的稳定性，不象发布分支（也许要永远支持），特性分支出生，使用了一段时间，合并到主干，然后最终被删除掉，它们在有限的时间里有用。 分支和标签 标签 分支被批准打包发布，纳入到标签下。许多标签代表了最终的发布版本。 分支和标签-”慵懒的拷贝” Subversion的版本库有特殊的设计，当你复制一个目录，你不需要担心版本库会变得十分巨大—Subversion并不是拷贝所有的数据，相反，它建立了一个已存在目录树的入口，这个拷贝被可以被认为是“懒的”，如果你提交一个文件的修改，只有这个文件改变了—余下的文件还是作为原来文件的链接存在。 这就是为什么经常听到Subversion用户谈论“廉价的拷贝”，与目录的大小无关—这个操作会使用很少的时间，事实上，这个特性是Subversion提交工作的基础：每一次版本都是前一个版本的一个“廉价的拷贝”，只有少数项目修改了。 当然，拷贝与分享的内部机制对用户来讲是不可见的，用户只是看到拷贝树，这里的要点是拷贝的时间与空间代价很小，所以你可以随意做想要的分支。 当然对于一个团队协作的项目来说，其分支的设定规则是需要经过项目团队认可、管理者审批的，否则会给其他人的协作带来混乱。 TortoiseSVN-创建标签和分支 分支 版本控制系统的一个特性是能够把各种修改分离出来放在开发品的一个分割线上。这条线被称为分支。 标签 版本控制系统的另一个特性是能够标记特殊的版本(例如某个发布版本)，所以你可以在任何时候重新建立一个特定的构件和环境。这个过程被称作标记。 使用提醒 分支和标签的实质是：建立了一个新的工作文件副本。 分支和标签意味着更多的维护版本，因此从配置管理角度来说，设置了只有经过项目经理审批才新建分支和标签。 TortoiseSVN-获取标签和分支中的文件 第一个方法：checkout Checkout，在本地任意位置创建新的工作副本。对于已经创建了工作副本的版本库，不建议采用此操作。造成多个本地工作副本，不便管理。 第二个方法：switch 对于已经checkout的版本库，可以在本地工作副本中使用switch方便的切换到该目录的任意历史版本。 注意：在工作副本里当进行本操作时，任何没有提交过的修改都会被混合。如果你不想看到这样的结果，那么你可以有两种选择，要么在切换前提交修改，要么把工作副本恢复到一个已经提交过的版本(比如必威体育精装版版本)。 在Eclipse中使用SVN-分支和标签 选择项目，单击右键--〉team---branch/tag。此步骤创建一个版本，选择存放目录，纳入到branch是分支，纳入到tag是标签。 继续开发项目的下一个版本。 发现bug，检出存在bug的版本。选择项目，单击右键---〉Replace With --- Another Branch or Version，选择存在bug的版本。 在当前工作空间（存在bug的版本）中修改程序，完成bug修改，编译测试。 将修改commit。测试。 重复…… 发布新版本。 在Eclipse中使用SVN-合并修改 这个命令包括三个参数： 初始的版本树（通常叫做比较的左边）， 最终的版本树（通常叫做比较的右边）， 一个接收区别的工作拷贝（通常叫做合并的目标）。 在Eclipse中使用SVN-合并修改 将一条分支的修改合并到另一条 切换出需要被合并的分支或者主干，并选中 鼠标右键-〉“Team”-”merge” “指定要合并的范围”-〉”起始路径“，选择版本号-〉”目标路径“，选择版本号 “合并” 结果：起始路径与目标路径版本之间的差异，将被合并到选中的分支或者主干 如出现冲突：手工修改 在commit前，该操作只针对本地工作副本，如放弃，“还原” 一切完成，同步，提交。 谢谢！ * * SVN版本管理初级培训 目录 SVN的基本概念 在TortoiseSVN中使用的SVN 在Eclipse中使用SVN 分支和标签 为什么要进行版本控制 是否发生过这样的情况: 当你在修改一个文件时，其他人也在修改这个文件？而你是否因此丢失过自己所作的修改呢？ 是否曾经保存完一个修改，然后又想把个文件恢复到修改以前的状态？是否曾经希望能够看到一个文件以前某个时间点的状态？ 是否曾经在项目中发现了一个 BUG，然后想调查它是什么时候产生的？ 你是否在一个团队中工作？ 如果这些问题中的任何一个回答“是”的话 那么你肯定需要考虑版本控制 请集中精力继续后续的培训。 Subversion相关软件 基于Subversion和TortoiseSVN的版本控制系统 Subversion：是一个开源的版本控制系统，拥有CVS的大部分特征，并在CVS的基础上有更强的扩展，用来代替