版本控制说明的.docVIP

Svn 版本控制 版本控制的必要性 版本控制(Revision control)是一种软体工程技巧，籍以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。能让你知道哪里改变了，以及代码的变化带来的影响一种是The Lock-Modify-Unlock Solution（锁-修改-解锁的解决方案）； 在这种方案下，每次只允许一个用户去进行修改，当用户要对文件进行修改时，必须先锁定该文件，此时其他用户就不能对文件进行修改了，只有当当前用户修改完文件，解锁该文件后，其他用户才能对该文件进行修改操作。 该方案有以下缺点：1）一旦用户在修改完文件后忘记解锁该文件，那么其他用户将永远不能或者通过其他方法解除该锁后修改文件，这会造成延时或者资源浪费。 2）当一个用户只修改文件的前半部分，而另外一个用户修改文件的后半部分，他们所要操作的内容并没有交集，他们可以分别同时进行修改然后将修改内容合并，完全没有必要按先后顺序依次进行修改 3）安全性 另外一种是The Copy-Modify-Merge Solution（复制-修改-覆盖的解决方案），目前的版本控制软件主要是以后者为主，一些特殊情况下采用前者进行版本控制。 实现思路是，每个用户对要修改的文件进行复制，然后用户可以同步地，独立地在自己的复制的文件里进行修改操作，最后再将修改的内容合并到原文件中，在该方案下，用户的工作是平行的，不需要彼此等待就可以对同一份文件进行操作，当然如果修改文件的同一部分就会出现冲突，但实践证明解决冲突的时间也远远小于加锁解锁的时间。 什么样的情况下采用The Lock-Modify-Unlock Solution方案？ 一般当所操作的内容是二进制文件（视频、音频文件）时，由于当冲突发生时，无法手动解决冲突，所以采用The Lock-Modify-Unlock Solution方案。 3、TAG\TRUNK\BRANCH区别联系 3.1 主干 主干，就是项目的整体，一个项目最初的所有文件都是在主干上，然后分支将主干的文件拷贝到各分支上进行独立开发，最终再将各分支的改动合并到主干上，也可以在主干上进行项目的开发操作。 3.1 分支 分支，顾名思义，就是开发线路允许存在另外一条独立的开发线路，就像树的树枝一样。创建分支就类似于将主干的内容复制一份给分支，然后主干和分支可以并行开发，最后将分支的改动合并到主干上（也可以将主干的改动合并到分支上），可以存在多个分支，在分支上所进行的修改如果没有显式的进行合并操作，其他分支和主干是看不到这些变化的。 ⑴创建分支 假设目前我们版本库中的项目的布局如下图： 如图所示，我们的项目放在了trunk（主线）目录，另外还有branch(分支)和tags(标签)目录，这样的布局是为了更清晰的区别主线、分支和标签三者的位置。subversion对分支和标签是通过复制一份最新的版本库的快照来实现的。开始创建分支：在我们CheckOut的主线目录(trunk)上，右键点击然后选择“Branch/tag…” 在弹出的窗口中，将To Url 指向branch目录并输入分支的具体目录名，这里是mybranch1.0，我们即将创建的分支便存放于此处，点击OK。 Update一下本地的branch目录，你就可以看到你刚刚创建的分支“mybranch1.0”，这样一来我们的分支就创建完成了。 创建分支的最大的目的就是跟主线进行并行开发的时候不影响主线的开发。 因为你在分支上所做的提交都只存于分支上，主线上的Update是看不到分支的修改的。如下图所示，trunk只能看到r344的版本，并看不到r343的版本。 （什么时候应该使用分支呢？例如你接到了一个任务，完成这个任务需要三四个人的合作，你们之间需要共享资源，那们就可以创建一个专为这次任务的分支，参与此次任务的人员则在分支上做开发，等完成之后再合并到主线上，才不会出现将实现了一半的不完成功能也提交到主线上，影响主线的正常工作。又或者自己需要一个较长的开发周期来完成任务，这么长的时间内如果一直没有将资源进行提交，万一丢失了就前功尽弃了。当然分支不是只用于此类情况，还有其它很多种情况也能使用分支来达到目的。） 使用分支需要注意,由于长期的独立开发，可能会在合并回主线时出现较多的冲突。所以在支线上开发间期如果发现主干有更新，而且这个更新有可能将来跟你产生冲突，那你可以先将主线的内容合并到分支上。已免等到做了大量修改再来更新。(其实此过程跟分支合并到主线上是一样的操作，只是目的地不同。) 例如我们在主线上的版本为3，我们如何将此版本的信息合并到分支上呢？ Merge…”。?在分支的根目录上右键点击，选择“TortoiseSVN 在这里我们必需先弄明白一个合并背后的关健概念