SVN 客户端用户使用手册该文档将逐步教您如何在软件开发过程中使用 svn 客户端环境模拟现有项目名称 :test 服务端版本库 :test URL: 开发人员 :deva,devb 版本库目录结构 : test Doc(word 文档 ) So

Size: px

Start display at page:

Download "SVN 客户端用户使用手册该文档将逐步教您如何在软件开发过程中使用 svn 客户端环境模拟现有项目名称 :test 服务端版本库 :test URL: 开发人员 :deva,devb 版本库目录结构 : test Doc(word 文档 ) So"

空兆
4 years ago
Views:

该文档将逐步教您如何在软件开发过程中使用 svn 客户端环境模拟现有项目名称 :test 服务端版本库 :test URL:http://10.155.11.10:81/svn 开发人员 :deva,devb 版本库目录结构 : test Doc(word 文档 ) Soc( 源代码 ) word_1 word_2 soc_1 sod_2 一.

1 该文档将逐步教您如何在软件开发过程中使用 svn 客户端环境模拟现有项目名称 :test 服务端版本库 :test URL: 开发人员 :deva,devb 版本库目录结构 : test Doc(word 文档 ) Soc( 源代码 ) word_1 word_2 soc_1 sod_2 一. 基本操作第一步 : 安装客户端到共享文件夹下, 下载 TortoiseSVN win32-svn msi 安装程序, 双击直接安装即可安装成功后, 右键单击鼠标会多出两个选项, 分别是 SVN checkout 和 Tortoise SVN 第二步 : 建立工作区项目开始之前, 在本地 PC 的硬盘上, 创建一个文件夹, 文件夹命名随意 ( 例如 workspace ), 该文件夹即作为软件开发者在项目开发过程中的工作区第三步 : 下载版本库假如现在开发一个项目, 配置管理员会在服务端建立一个该项目的版本库 test 在 workspace 文件夹上, 右键单击鼠标选择 SVN checkout, 会出现如下窗口图 1 在 URL of repository 中输入版本库地址, 在 Checkout dir 中系统会自动添加第二步所创建的工作区目录在 Revision 中, 选中 HEAD revision, 这样将会下载到版本库的最新版本如果想下载库中的旧版本文件, 可选中 Revision, 然后填入版本号即可

2 如果不想下载整个版本库, 而是只想下载自己负责的那部分模块, 可以在 URL 后添加模块名, 例如单击 OK, 输入用户名和密码第四步 : 修改版本库对版本库的修改包括修改文件内容, 添加删除文件, 添加删除目录经过第三步的操作, 本地的工作区文件夹, 即 workspace 上会有绿色对勾出现, 工作区下的文件也会带有绿色对勾, 如图 2 图 2 如果对库中某一个文件进行了修改, 系统会自动为这个文件和这个文件所在的各级父文件夹加上红色叹号, 代表该文件或目录已经在本地被修改, 如图 3 图 3 当所有对版本库的修改操作完毕后, 右键单击工作区文件夹, 选择 commit 提交新版本, 输入密码后系统将把修改后的版本库上传到服务端, 即完成一次对版本库的更新注意 : 新版本提交之后, 其他拥有写权限的用户也许会重复以上几步的操作, 完成对版本库的再一次更新所以, 每次在工作区文件夹下修改本地版本库之前, 必须首先对本地版本库执行一次更新 ( 右键单击工作区, 选择 SVN Updata), 将最新的版本下载到本地, 然后再进行修改操作二. 其他操作在日常的软件开发过程中, 除了以上介绍的下载, 提交, 更新操作外, 还有另外几种常用操作 (1) 比较文件的不同之处当对 soc_1 做了修改之后,soc_1 文件会出现红色叹号, 表示已经修改, 如果想查看修改后的 soc_1 文件与修改前有何不同, 可以右键单击此文件, 选择 diff, 系统探出一个窗口, 如图 3, 窗口分为两个部分, 左边为更改之前的版本, 右边为更改之后的版本并在不同之

3 处作出标记和说明如图 4 图 4 如果是 word 文档的话, 选择 diff 之后, 系统会打开一个 word 文档, 并在其中标出修改后的版本与修改前有何不同如图 4.1 图 4.1 (2) 查看日志如果想查看一个文件的日志, 例如 soc_1, 右键单击这个文件, 选择 show log, 系统会踏出一个窗口, 并在窗口中显示 soc_1 各个版本的 log 如图 4 (3) 查看版本树图 5

如果想查看 soc_1 文件的版本树, 右键单击该文件, 选择 Revision graph, 系统将会打开一个窗口, 并在窗口中显示该文件的版本树如图 6 图 6 之所以只显示了 4.5.6.7 四个版本, 是因为选择了只显示发生过变化的版本即 1.

3 两个版本是与版本 1 相同的 (4) 下载某个文件的旧版本如果想要得到某个文件的旧版本, 只需在该文件上单击右键, 选择 Updata to revision 即可系统会提示输入版本号例如要下载 soc_1 的第五个版本, 只需填入 5

4 如果想查看 soc_1 文件的版本树, 右键单击该文件, 选择 Revision graph, 系统将会打开一个窗口, 并在窗口中显示该文件的版本树如图 6 图 6 之所以只显示了四个版本, 是因为选择了只显示发生过变化的版本即每一个版本都有不同的地方, 都是经过用户修改后提交的而 2.3 两个版本是与版本 1 相同的 (4) 下载某个文件的旧版本如果想要得到某个文件的旧版本, 只需在该文件上单击右键, 选择 Updata to revision 即可系统会提示输入版本号例如要下载 soc_1 的第五个版本, 只需填入 5 即可如图 7 查看完版本 5 的文件后, 如果想在此回到最新版本, 只需要对 soc_1 运行 Updata 即可图 7 (5) 重名名和删除文件如果要删除一个文件或重名名一个文件, 注意不要在 windows 下直接操作只需右键单击该文件, 选择 Rename 或 Delete,svn 系统便会完成操作在 workspace 中将文件重命名或删除后, 服务端的文件结构不会变化, 只有当提交新

版本库后, 即 commit 后, 服务端的文件结构才会被更新如果误删除了文件, 在没有提交版本库之前, 可以通过对版本库的升级将文件重新下载到本地的版本库, 也可以通过 revert 恢复 ( 参考第八条 ) 如果文件删除, 并且已经提交, 那么要找回文件只能通过下载旧版本库来完成, 参考 (4) (6) 创建分支版本库中最初的文件 soc_1,soc_2,word_1,word_2

5 版本库后, 即 commit 后, 服务端的文件结构才会被更新如果误删除了文件, 在没有提交版本库之前, 可以通过对版本库的升级将文件重新下载到本地的版本库, 也可以通过 revert 恢复 ( 参考第八条 ) 如果文件删除, 并且已经提交, 那么要找回文件只能通过下载旧版本库来完成, 参考 (4) (6) 创建分支版本库中最初的文件 soc_1,soc_2,word_1,word_2 都是主干文件如果想要为 soc_1 创建一个分支, 只需右键单击 soc_1, 选择 Branch/Tag, 系统会弹出一个窗口, 如图 8 在窗口中,From URL 表示要创建的这个分支是 soc_1 的分支 ( 系统会自动添加, 不必更改 ) 在 To URL 中, 需要更改一下文件名, 在文件名后加一个标志即可, 例如 _branch, 路径不需要更改在 Creat copy in the repository from 中, 可以选择分支文件是由 soc_1 的那一个版本拷贝来的最后填写日志, 选择 OK 图 8 分支创建完毕,Updata 版本库, 系统会将 soc_1 的主干文件和分支文件 soc_1_branch 同时下载到本地版本库, 如图 8.1, 然后即可在分支文件上进行操作此时 soc_1 的版本树如图 8.2 图 8.1

表示已被修改, 并可以提交如果合并后文件标注的是黄色叹号, 表示文件有冲突, 处理方法见第三部分异常处理 (8) 撤销修改当对一个文件进行了修改并保存后 ( 注意此处并没有进行提交 ), 如果对修改不满意,

6 图 8.2 (7) 合并分支当需要把 soc_1_branc 分支文件合并到 soc_1 主干文件时, 右键单击 soc_1, 选择 Merge, 会弹出一个窗口, 如图 9 图 9 在 From 输入框中填入主干的 URL, 在 To 输入框中填入分支的 URL 在 From 和 To 中, 都有两个选项 HEAD Revision 和 Revision, 表示要进行合并的是 soc_1 的那个版本合并之后主干文件会标注红色叹号, 表示已被修改, 并可以提交如果合并后文件标注的是黄色叹号, 表示文件有冲突, 处理方法见第三部分异常处理 (8) 撤销修改当对一个文件进行了修改并保存后 ( 注意此处并没有进行提交 ), 如果对修改不满意, 想要重新修改, 可以右键单击修改过的文件 ( 带红色叹号的那个 ), 然后选择 revert, 前面的一系列修改便会被撤销, 恢复到 Updata 之后的状态如果一个文件被误删除, 也可通过右键单击该文件所在的目录, 选择 revert 来恢复

三. 异常处理此处所说的异常主要是指文件发生冲突以用户 deva 和用户 devb 为例, 当两个用户同时下载了最新的版本库, 并对库中同一个文件 soc_2 进行修改提交时, 首先提交的用户 deva 不会发生异常, 第二个提交的用户 devb 便会出现无法提交的现象因为服务端的版本库已经被 deva 更新,devB 用户在上传时, 系统会提示出错如图 10 在这种情况下,devB

7 三. 异常处理此处所说的异常主要是指文件发生冲突以用户 deva 和用户 devb 为例, 当两个用户同时下载了最新的版本库, 并对库中同一个文件 soc_2 进行修改提交时, 首先提交的用户 deva 不会发生异常, 第二个提交的用户 devb 便会出现无法提交的现象因为服务端的版本库已经被 deva 更新,devB 用户在上传时, 系统会提示出错如图 10 在这种情况下,devB 用户需要首先对修改的文件进行 Updata 文件操作如果两个用户修改了文件 soc_2 的同一个地方, 则在 devb 用户执行 Updata 后, 系统会将本地的 soc_2 与从服务端下载 soc_2 合并到一个文件上, 并在该文件图标上标上黄色叹号, 表示文件出冲突在文件中通过 <<<<<< 和 >>>>>> 标识冲突位置和冲突内容 devb 用户只有与 deva 协商, 将该冲突处理, 之后单击右键, 选择 Resolve, 冲突标记消除, 才能够再次提交, 否则无法提交文件标记冲突的格式 : <<<<<<<.mine workspsace 工作区, 等 abc 工作区提交结束后再提交, 应该会出现冲突 ======= 在此插入一段话, 啊啊 aaa, 测试冲突 >>>>>>>.r15 绿色部分表示本地文件的修改蓝色部分表示服务端版本库中的最新版本与本地文件修改发生冲突的地方紫色表示是第 15 个版本发生了冲突

Git 原理简介 Git 是一种分布式版本控制系统每个克隆的仓库都包含有整个仓库的所有数据任何修改先提交在本地, 再推送到服务器创建和切换分支合并修改相当方便而且快速本文档中第一次出现的术语将以蓝色斜体标出术语的含义是单一的明确的不可替代的 1

Git 原理简介 Git 是一种分布式版本控制系统每个克隆的仓库都包含有整个仓库的所有数据任何修改先提交在本地, 再推送到服务器创建和切换分支合并修改相当方便而且快速本文档中第一次出现的术语将以蓝色斜体标出术语的含义是单一的明确的不可替代的 1 Git 原理简介 Git 是一种分布式版本控制系统每个克隆的仓库都包含有整个仓库的所有数据任何修改先提交在本地, 再推送到服务器创建和切换分支合并修改相当方便而且快速本文档中第一次出现的术语将以蓝色斜体标出术语的含义是单一的明确的不可替代的 1 Git 仓库结构举例 git@my.server:bob/my.git master A B C 2 Git 仓库结构相对本地已克隆的仓库而言,

SVN 客户端用户使用手册 该文档将逐步教您如何在软件开发过程中使用 svn 客户端环境模拟现有项目名称 :test 服务端版本库 :test URL: 开发人员 :deva,devb 版本库目录结构 : test Doc(word 文档 ) So

SVN 客户端用户使用手册该文档将逐步教您如何在软件开发过程中使用 svn 客户端环境模拟现有项目名称 :test 服务端版本库 :test URL: 开发人员 :deva,devb 版本库目录结构 : test Doc(word 文档 ) So