超简单的SVN快速入门

1、SVN介绍

  SVN是Subversion的简称，是一个自由开源的版本控制系统。
  Subversion将文件存放在中心版本库里，这个版本库很像一个普通的文件服务器，不同的是，它可以记录每一次文件和目录的修改情况，这样就可以借此将数据恢复到以前的版本，并可以查看数据的更改细节。

1.1 SVN基本概念

  问题: 怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？
  复制-修改-合并方案(Subversion默认的模式)：在这种模型里，每一个客户读取项目配置库建立一个私有工作副本——版本库中文件和目录的本地映射。用户并行工作，修改各自的工作副本，最终，各个私有的复制合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要靠人工去确定正误。
  锁定-修改-解锁方案：在这样的模型里，在一个时间段里配置库的一个文件只允许被一个人修改。 此模式不适合软件开发这种工作。

1.2 SVN架构

  Subversion支持Linux和Windows，更多是安装在Linux下。
  svn服务器有2种运行方式：独立服务器和借助apache运行。两种方式各有利弊，用户可以自行选择。
  svn存储版本数据也有2种方式：BDB一种事务安全型表类型和FSFS一种不需要数据库的存储系统。
  因为BDB方式在服务器中断时，有可能锁住数据，所以还是FSFS方式更安全一点。

2、SVN安装与使用

  本章节主要介绍常用的svn工具，如window下svn服务器VisualSVN，客户端工具TortoiseSVN以及idea svn插件的使用。
  SVN是一种集中式管理代码的版本控制系统，原理就是把代码都保存到一个固定的位置（仓库），每次从这个位置拷贝更新代码，进行编辑；再把修改后的代码提交到该目录中。多人协作开发也是如此。因此需要一个类似Oracle或者Mysql的服务器用于保存和管理库文件（要保存的代码等文件）的服务端——VisualSVN Server。还需要一个用户的操作端，用于提交更新检出代码，常用的有idea的Svn插件，以及TortoiseSVN（小乌龟）。

2.1 下载

  SubVersion官网：http://subversion.apache.org/
  选择二进制包：

  把这两个下载下来

2.2 安装

2.2.1 服务端VisualSVN的安装

  安装完即可在服务中看到，启动服务即可。

  图形化管理界面：

2.2.2 客户端TortoiseSVN的安装

  直接双击下一步，走到这一步要注意，command line client tools默认是不安装，要改为安装，否则IDEA配置不了。

  改为：

  安装完重启电脑，否则有些东西没生效。
  随便打开一个文件夹，鼠标在空白处右键即可看到SVN Chexkout...和TortoiseSVN选项。

2.3 使用

  使用的逻辑是，SVN分为服务端和客户端，服务端存放代码，进行版本控制，客户端是用户写代码使用的。

2.3.1 VisualSVN创建仓库目录

  右键选择Repositories，选择Create New Repository，选择FSFS类型，输入名称，选择Empty repository，然后一直下一步。即可创建一个空白仓库目录，用于存放代码。比如我创建一个仓库叫做ssm：

  其实这里的ssm就相当于一个文件夹。

2.3.2 VisualSVN创建用户和组

  客户端连接服务端来拉取代码，连接至少需要提供两个信息：账号密码+仓库地址。因此要给每个程序员创建角色，比如我这里创建两个角色aaa、bbb和ccc，密码都是admin：

  创建好Users后，我们观察到下边还有一个Groups，这是组，用于权限控制的时候选择，我们把aaa和bbb用户设置为一组，给起个名字”ssm开发组“，表明ssm仓库的代码是这个小组来写的。

2.3.3 VisualSVN权限控制

  权限控制指的是给仓库添加权限，运行哪些用户访问，运行哪些操作等。
  刚才创建ssm仓库时，其中一个步骤就是选择权限，当时没有创建用户，就默认所有用户都可访问修改。现在要把ssm仓库改成只有ssm项目组才能访问，右键选择ssm仓库，选择Properties，设置成如下：

2.3.4 TortoiseSVN常用操作

  一般情况下，服务端是安装在远程服务器，我们程序员都是使用TortoiseSVN来连接服务器端对代码进行版本控制。
  假设公司现在要做一个ssm项目，公司有一个专门管理仓库的管理员已经把空白项目仓库ssm创建好了，公司有三个程序员，分别是小A、小B和小C，领导决定让小A和小B来做这个项目，仓库管理员给他们两个分配的仓库账号aaa和bbb。由小A来主导项目。
  仓库管理员要把仓库的URL发给了小A和小B，于是管理员右键ssm仓库，选择Copy URL to Cliboard，然后粘贴发给小A和小B。

2.3.4.1 浏览仓库

  现在小A安装好了客户端TorroiseSVN，开始做这个ssm项目了，首先他要把自己本地和远程仓库进行关联，新建一个空白文件夹，右键选择TortoiseSVN，选择Rep-browser，把管理员给的仓库URL输入，弹出窗口让小A输入账号密码，小A输入属于他的账号密码：aaa/admin

  输入后，小A可以连接远程仓库了，此时还没有和ssm仓库有关联，只是登陆了而已。
  右键选择SVN Checkout：


  这个选项是把仓库下载到本地，Finished后可以看到在文件夹中只有一个.svn文件夹，这时因为项目还没开始，仓库是空的，这个.svn目录表明这个文件夹被svn客户端管理了（不代表这个文件夹下所有文件都给SVN客户端管理了）。

  鼠标右键当前文件夹，对比不在当前文件夹鼠标右键，发现鼠标右键的菜单选项不一样了。也可以看到小A程序员建立的名字叫做“小A”的文件夹图标也变化了。

  进入到“小A”文件夹，小A程序员开始写代码了，创建一个HelloWorld.java文件，然后什么都不写：

2.3.4.2 add

  选择这个文件，右键TortoiseSVN，选择Add，可以看到文件图标发生变化.表明这样图标的文件由SVN客户端管理了。

2.3.4.3 commit

  小A表示，我要休息了，于是右键空白处，会发现多了一个SVN Commit选项，选择：

  选择OK后，就把这个代码提交到远程仓库了：

  这时，仓库管理员就可以看到ssm仓库有东西了，不是空白了，可以跟老板汇报程序员开始干活了。

2.3.4.4 update

  本章的演示都是在一个计算机上，实际是服务器、程序员A和程序员B三方都是在各自的电脑上的。所以为了让小A程序员去休息，让小B程序员开始干活，先把小A程序员的登陆信息给清空。
  右键空白处，选择TortoiseSVN，选择Settings：

  现在小B程序员登场了，还是熟悉的操作，小B程序员新建一个叫做“小B”的空白文件夹，跟上面小A程序员一样的操作，连接仓库地址+登陆。

  小B程序员连接ssm仓库时还能看到小A程序员的commit记录。
  登陆后，还是右键空白处，选择SVN Checkout：

  这里要注意，小B下载的是版本1。

  跟小A程序员不同的地方在于，小B程序员下载的仓库不是空的，因为小A程序员提交过嘛。
  搞了那么久，到底update是干嘛的？其实update的作用是更新操作。假设小B下载了这个项目是版本1，然后小B出去玩了一天回来才开始干活，而这期间，很可能小A程序员又改了什么东西，又提交了一次，导致远程仓库已经是版本2了。那么小B程序员还在版本1上修改，就不对了。因此，为了保证小B程序员修改的是在最新版本的基础上，于是，右键空白处可以看到一个update，选择后：

  小B程序员一看，耶，还是版本1，说明小A没有再次提交过，可以放心写代码了。
  小B程序员最好在开始写之前进行一次update，以保证自己开始写的地方是最新版本。
  update操作后，小B程序员开始写代码了，修改了HelloWorld.java：

  这时发现这时发现文件图案出现感叹号，暂时不理他，直接commit。此时远程仓库的ssm变成版本2了。

2.3.4.5 冲突问题与解决

  小A程序员又开始干活了，此时他本地因为已经有了ssm项目，就不用再下载，只需要update一下就可以更新到最新版本了。

  可以看出，现在小A修改的是版本2，于是小A开始修改这个HelloWorld.java：

  此时小A程序员开始思考下一句代码要写什么，并没有commit代码，远程仓库最新版本还是版本2。
  这时，小B程序员上线了，他也熟练地update一下，因为远程仓库自从版本2以来还没更新过，所以小B程序员也是版本2基础上开始工作。

  小B程序员也开始修改代码：

  然后小B程序员提交了代码：

  此时，远程仓库的版本变成了版本3。
  话分两头，小A程序员这边可就麻烦了。
  小A程序员冥思苦想，还是不知道下一句要写什么，于是先提交了，等下次有灵感了才继续写。这时问题来了，小A修改的版本是基于版本2的，但这时的远程仓库已经是版本3了。所以小A执行commit操作时，出现以下情况：

  怎么办，小A程序员只能update了，update之后，多产生了几个文件：

  HelloWorld.java：远程仓库版本3和本地文件的合并；
  HelloWorld.java.mine：小A程序员基于版本2修改后的文件（即刚才准备提交的文件）；
  HelloWorld.java.r2：版本2的文件；
  HelloWorld.java.r3：小B程序员提交后成为版本3的文件。
  小A程序员于是就根据第一个远程仓库版本3和本地文件的合并来编辑冲突，右键选择HelloWorld.java，选择TortoiseSVN，选择Edit conflicts：

  左边就是HelloWorld.java.r3，右边是HelloWorld.java.mine，下边就是合并后的结果，小A程序员就得决定如何合并了。
  可以看出，冲突就在于第三行，小B程序员定义了一个变量，小A程序员为了不改小B定义的变量，决定兼容合并，右键选择冲突行，选择Use text block from ‘mine’ befor ‘theirs’，修改成如下：

  然后执行commit：

  可见，此时远程仓库已经更新到版本4了。

2.3.4.6 更新到历史版本

  小A程序员突然灵光一闪，不行，我得回到版本2，我在版本2的基础上修改完忘记测试了，现在版本4出现问题了。于是小A程序员右键选择TortoiseSVN，选择Show log：

  可以看到，ssm项目的提交历史。
  右键选择版本2，选择如下：

  于是乎，小A程序员的本地版本变为版本2了：

  打开文件一看：

  没错，小A开始重新修改了。

2.3.4.7 delete

  老板听说了小A和小B这样瞎折腾，对这个HelloWorld.java不抱希望了，命令小A删除它，重新写。
  小A程序员update后，首先标记delete操作，右键选择该文件，选择TortoiseSVN，选择Delete。此时该文件已经在本地文件夹消失了。但是这个操作没有影响到远程仓库，小A程序员再commit一次，远程仓库就删除这个文件了。

  此时远程仓库变成了版本5，版本5是没有HelloWorld.java这个文件的。

3、IDEA集成SVN

3.1 配置

  IDEA集成SVN，其实就是把客户端TortoiseSVN集成到IDEA中。

  这样，就集成好了。

3.2 基本使用

  现在我本地已经写好了一个完整的ssm项目，准备放到远程ssm仓库。
  远程仓库新建一个，其中一步选择以下：

  生成结果如下，其实就算多了三个空文件夹。

  第一步：选择share project

  第二步：导入远程仓库ssm的地址

  第三步：选择share

  第四步：选择版本，选1.8即可

  第五步：为了完成share操作，进行一次commit

  第六步：点add即可

  第七步：commit


  这时候远程仓库变成了这个样子：

4、SVN规范

4.1 SVN目录规范

  在visualSVN中创建仓库时，可以选择svn目录结构：
  Trunk ：主干目录，此目录下的文件为基准文件
  Branches：用于开发的分支目录
  Tags：用于发布的版本目录
  假设有一个项目ssm，我们完成了1.0版本，这时就可以打一个tags。
  后续我们在ssm项目上添加一个新的模块(比如：通讯),我们就可以开一个分支,又有一个公司需要在我们ssm基础上添加财务管理模块，我们又可以打一个分支。
  我们后续针对ssm的1.0版本在升级，我们不需要原来附加功能,就可以在原来的主干上继续开发，形成ssm 2.0版本，开发完成后就可以在打一个tags。

4.2 分支与标记

  分支branches的定义规则：Project name+日期时间+功能点
  标记Tags的定义规则：Project name+版本号
  版本号定义为三段数字编号 xxx.xxx.xxx
    第一个:革命性的产品升级版
    第二个:新功能版
    第三个:修正bug。

4.3 打分支或标记

  假设我根据需求，添加了一个test类。

  现在要把整个项目打成一个分支：

  说清楚从哪来到哪去。

  点击OK后，远程仓库即可多一个分支

  Tags一般是只读，它代表的是发布的版本，所以我们不要进行改变。