版本控制之SVN(一)

SVNJava版本控制器
 
SVN的定义：帮助参与项目人员管理项目资产，项目资产包括：源代码、文档、测试和构建脚本等。（版本控制器，是支撑项目开发的基础工具）

版本控制中使用术语：
项目仓库：储存各种版本项目文件的地方 ；项目仓库放到服务器端，版本控制工具做客户端
可以控制什么：我们存储的内容：有源代码、脚本、元数据、文件 （可以通过一个简单测试，如果没有这个东西的最新版本，对于我们的工作有没有影响》）
 
工作copy ：从服务器端将数据仓库中存储内容放到我们本机的位置上，也称为：工作目录或工作场点。
 
签出：为了第一次建立我们的工作copy，需要从项目仓库中拿些东西出来。当从项目签出一些东西时，就是把文件复制一份到我们的工作copy。签出过程保证所需文件是最新
版本，并且目录和仓库中一致。
 
导出：导出的只是一个项目仓库文件的快照，而不是工作拷贝。打包发行代码时可以使用。
 
提交：在本地工作拷贝中修改项目代码，然后将改动又存回到数据仓库项目中去。
 
更新（签出）：项目仓库中项目被别人修改后提交了，你必须将更新内容“更新到”你的工作拷贝。
 
项目、模块、子模块
版本号、
标签、
主干trunk、
 
分支：平行的世界，使用这个分支的人可以看到它包含的代码并独立的进行操作，不会影响到工作在其他分支或者主干上的人。每个分支有自己的历史记录还能与主干独立地区跟踪改动。以发布为目的，可以通过分支拥有稳定的代码，然后再次基础上润色，最后成功发布。与此同时大队伍开发人员可以继续主线代码的开发。当顾客报告在发布版本中发现了问题时，团队可以从发布分支中找到代码，从而可以修改bug并发布更新过的版本，不用包含任何从主干那过来的新开发的代码。但是我们应该避免过度使用分支。因为在不同分支间合并改动是有高昂代价的（合并改动行，并确保没有丢失改动）。
 
合并：你在一个分支上修正了一个BUG,并且意识到同样的bug在主干代码中也存在。我们可以通过版本控制器系统找出这个修正，并把改动应用到主干代码上。甚至可以把改动合并到数个不同发布版本的分支中。
 
锁：严格枷锁,乐观枷锁
     严格枷锁：签出的所有文件一开始都被标记为只读。可以阅读，可以构建系统，但是不能编辑、修改、要编辑、修改必须征询项目仓库的统一。如果别人要编辑你正在编辑的文件，数据仓库会拒绝你的要求。你要修改只能等待别人修改过后然后签入之后再进行处理。
     乐观枷锁：所有开发人员都能编辑所有签出的文件，但是项目仓库不会让你随便进行签入自你上次签出之后已经被更新的文件。他会让你先更新本地的文件，包含项目仓库所有最新改动之后再来签入。版本控制器不会简单以项目仓库中最新版的文件去覆盖你辛苦改过的文件，而是尝试去合并项目仓库中有的改动和你本地的改动。如果改动的是同一个地方，需要手工解决冲突。
  对于配置文件或者说是无法合并的文件，需要严格加锁。

功能：
（1）提供项目级别撤销的可能；
（2）协调团队开发，避免团队成员开发的代码互相覆盖；
（3）SVN记录每次提交的改动，允许恢复旧版本的数据，或者追查数据变化的历史；
（4）SVN允许团队在保持诛仙开发的同时，建立发布分支，并在发布分支上修改BUG；
.....

提交：用本地文件覆盖服务器上的文件，结果是提交后导致服务器上发生变化
 
更新：只是把服务器上最新版本下载到客户端，规则是：
（1）如果本地某个文件没有修改过，而服务器上的这个文件别人已经提交过新版本，那么会用服务器上最新的文件覆盖你的本地文件；
（2）如果你本地的某个文件你修改过了还没有提交，服务器端的这个文件还没有被别人修改过，那么对你本地的这个文件没有任何影响；
（3）如果你本地的某个文件你修改过了还没有提交，服务器端的这个文件已经被别人改过，那么会提示你发生冲突，会将服务器上最新版文件和你新修改的文件、发生分歧前的那个版本的文件都存放到你本地
 
资源库同步：查看你本地和服务器之间版本的差异，你直接用更新，有时会出现冲突，丢掉自己代码。资源库同步目的让你知道那个文件有冲突，然后有选择的更新。因此在操作之前可以通过资源库同步查看有差异代码，然后进行有选择操作。
update  to version将服务器上工作copy一份到本地，注意一般选择Working copy,其他类型可能会导致出现一些意外,update to head revision 表示恢复到最新版本