subversion的最基本使用30204.docx

1、subversion的最基本使用30204版本控制subversion简介和使用一、Subversion简介Subversion 是一个自由/开放源码的版本控制系统，也就是说Subversion 管理着随时间改变的档案。这些档案放置在一个中央档案库(repository)中。这个库很像一个寻常的档案服务器，不过它会记住每一次档案的变动。这样你就可以把档案回复到旧的版本，或是浏览档案的变动历程。如图所示：Repository好比就是一个服务器端，存放着不同的版本，client是客户端，可以读取和修改服务器中的各种版本。当中央文档库中的某个版本文档被修改时，subversion会记录每一次的修改，

2、并且系统的记录每一次的改变。Subversion版本控制的工作原理总结起来就是“拷贝修改合并”“拷贝”：每个用户从版本库中复制出一个版本供自己使用，版本库中的版本保留不变。一个用户甚至可以拷贝一个项目的多个版本，这些都属于自己的私人工作区。“修改”：每个用户都可以对自己拷贝出来的版本进行修改，这个修改是在自己的环境下完成的，不影响版本库中的原始版本“合并”：当第一个用户修改完成后，他可以提交自己的新版本到版本库中，版本库会记录下他的新版本，稍后，当第二个用户提交自己的修改时，版本库会提示第二个用户，版本库中还有第一个用户提交的版本，此时，第二个用户可以将第一个用户的版本下载到自己的客户端，查看

3、所修改的地方，同时，可以整合两个版本，最后形成一个最新的版本，并且提交到版本库中如下图所示：二、Subversion的使用Subversion的服务器端和客户端已经搭建完毕。在服务器端，我们构建一个版本库repos1，并且配置了用户的账户wwd3020400,wwd3020401,wwd3020402。在客户端，我们建立了三个独立的工作区间work3，work4，work5来模拟三个不同的工作用户首先，我们将一个项目放在一个文件夹workspace里面，并将这个项目的所有文件导入到服务器端的版本库repos1中选择“导入”，如下图所示在“版本库URL”中输入SVN:/ 地址 仓库名称输入账户和

4、密码即可导入成功当这个项目文件导入到版本库后，这个版本将会被定义为版本1，因为版本库中最初的空状态是版本0，我们可以在版本浏览器中查看到该项目的版本1，如下图所示此时，不同的用户可以在版本库中拷贝这个工作副本到自己的工作空间进行操作。使用“检出”命令，将整个项目文件夹拷贝到客户端确定得到检出的项目文件我们假设三个独立的工作区间就是三个不同的程序员在对同一个项目进行修改等操作，将版本库中的项目也拷贝到work4和work5中添加新的文件现在，work3，work4，work5三个工作区间中都有了相同的工作副本，我们对work3的副本添加一个文件add.txt,同时add.txt上出现了一个蓝色的

5、问号，我们右键，点击“SVN提交”新的文件add.txt已经被加入了版本库，同时，版本库会给与一个新的版本号2，表示不同于先前的版本1，此时，我们刷新版本库浏览器，也会看到新加入的add.txt文件同时，我们也注意到，add.txt的版本号为2，不同于其他文件的版本号然后我们在work4工作区间中，右键，“SVN更新”可以发现，work4的工作区间多了add.txt这个文件，来源于版本2的，此时work4中的工作副本即为版本库中最新的版本了，相对于work5，工作副本还是版本1的，因此work5中并没有新增加的add.txt文件修改项目中的文件假设在work3的工作区间下，修改了项目中的文件t

6、ext.txt，此时，text.txt文件上会出现一个红色的感叹号，表示该文件已经被修改过了。然后“SVN提交”完成修改后，版本库中得到了一个新的版本3，如果现在更新版本库，可以看到text.txt已经是新版本号3了同样，更新每个工作区间的文件，都会得到修改过的text.txt文件，也就是说，每个工作区间都是最新的版本3，这个新版本中可能有的文件完全没有被修改过，版本号还是最原始的1（指版本3中的某些文件），但是在subversion中更新后的版本统称为版本3，如果新建一个工作区间，检出版本2，那么在这个新的工作区间中，版本2下是看不到对text.txt文件的修改的多人同时修改了同一文件并且提

7、交在实际情况中，很多时候会出现两个人或者多个人对同一个文件进行修改，比如说，在一个工作区间work4中修改了一个文件的几处代码，在另一个工作区间work5中修改了同样文件的另外几处代码，如果是A先提交他的修改刷新版本库可以看到w1文件夹变成了版本4此时，work4工作区间完成了修改并成功提交了自己的修改在work4完成提交后，work5工作区间也完成了修改，并且向版本库提出提交申请出现了提交错误，因为work5工作区间中的w1文件已经过时了，w1文件在版本库中有了更新，为了保护版本库中的更新，不允许其他用户进行write操作，而必须先更新了自己本地的工作区间，看到了新的更新版本，才能提交自己的

8、修改，如下图所示完成了版本库的更新，同时，版本库中的文件有了最新的版本号5还有另一种情况，两个用户对同一个文件的同一个地方进行修改，也会出现冲突比如对work4的文件修改后提交显示冲突后，我们可以再work4的工作区间找到这个冲突点带感叹号的文件即为冲突文件，还有三个带问号的文件，对应于不同的后缀名，表达不同的意思，后缀名为mine的表示的是自己修改的文件版本，后缀名为r4的文件表示的是版本4下的该文件内容，后缀名为r5的文件表示的是版本5下的该文件内容当发生冲突后，需要去解决冲突，这时候需要人为的去商定和解决我们可以去比较两个不同文件的差异通过对比和协商后，可以选取不同的解决方式，比如将wo

9、rk4下做出的修改进行还原，当冲突解决后，右键TortoiseSVN，选择“已解决”，然后重新提交修改分支与合并所谓分支，如下图所示具体实例解释：假定A和B两个用户都有“calc”的工作拷贝，更准确的说是/calc/trunk的工作拷贝，因为这个项目所有的文件都在这个子目录里面，此时，A用户有个任务，对这个项目进行一个重新的整合或者大的修改，这个时候就需要大量的时间来做这个工作，但是B用户可能正在处理这个项目的一些小bug，一直在使用/calc/truck的最新版本，如果A一点一点的提交他的修改，会对B的工作出现干扰最佳方法：创建属于A自己的分支，也称为版本库的开发线，这样可以在这个新的开发线中保存A的工作而不打扰到B如下图所示这是一种“代价低廉”的拷贝方式，因为subversion下复制一个目录的时候，并不是拷贝了所有的数据，而是建立了一个已存在目录树的入口，如果提交一个文件的修改，只有这一个文件改变了，余下的文件还是作为原来文件的链接而存在。其实，这个拷贝出的分支，只是这个目录的一个镜像而已，当A提交自己的相关修改到这个分支中的时候，B在更新时是不会看到改变的，因为B的工作目录是/calc/trunk分支后，也可以进行合并手工追踪合并：需要在日志中查看修改，并且查看所有的修改后再手动选择合并