SVN

第一次设计并发布 Subversion 时, 它的主要版本控制策略是 集中式的版本控制 (centralized version control)—有一个远程 的主仓库, 仓库中存放了被版本控制的数据, 用户在本地操作数据的浅拷贝副本. Subversion 发布后, 很快就显现出它在版本控制领域的领导地位, 它的使用范围 越来越广泛, 越来越多的旧版本控制系统被它取代, 即使是在今天, 它在版本控 制领域也占据着重要地位.

从那时起也发生了很多事情. 在 Subversion 开始出现的那一年, 一种新的版本控制 策略—分布式的版本控制 (distributed version control)—开始受到越来 越多的关注, 应用也越来越广泛. 一些版本控制工具, 例如 Git (http://git-scm.com/) 和 Mercurial (http://mercurial-scm.org/) 成为了分布式版本控制系统 (DVCS) 的宠儿. 分布式的版本控制利用不断提高的网络连接速度和低廉的存储 开销, 提出了一种和集中式模型完全不同的方法. 首先最明显的区别是它们不 需要一个远程的中央仓库, 每一个用户在本地都有一份完整的版本历史. 用户 之间仍然需要协作, 但不需要通过一台中央节点, 可以直接进行交互.

svn
客户端命令行工具

svnversion
用于报告工作副本状态 (就项目的版本号而言) 的工具

svnlook
可以直接检查仓库的工具

svnadmin
用于创建, 调整或修复 Subversion 仓库的工具

mod_dav_svn
可插拔的 Apache HTTP 服务器模块, 该模块允许用户通过网络访问 仓库

svnserve
一个定制的, 可独立运行的服务器程序, 可以以守护进程方式运行, 也可以被 SSH 调用, 这是另一种允许用户通过网络访问仓库的方法

svndumpfilter
过滤 Subversion 仓库转储数据流的程序

svnsync
可以跨越网络对仓库进行增量镜像备份的程序

svnrdump
可以跨越网络对仓库历史进行转储和加载的程序

svnmucc
该工具支持在没有工作副本的情况下, 在一个单独的提交中对多个 仓库执行基于 URL 的操作

版本控制系统的核心是仓库, 它是存放系统数据的中央位置

复制-修改-合并 解决方案

Subversion 为工作副本中的每一个文件记录两项信息:

• 文件的版本号 (这被称为文件的 工作版本号 (working revision))

• 一个时间戳, 记录了本地文件最近一次被仓库更新是在什么时候

有了这些信息后, 通过与仓库通信, Subversion 就可以判断出 每一个工作文件处于以下 4 种状态中的哪一种:

当前未修改的

文件在工作副本中未被修改, 并且在工作版本号之后还没有 人提交过该文件的修改. 对文件执行 svn commit 和 svn update 都不会产生任何效果.

当前已修改的

文件在工作副本中已被修改, 并且在一次更新以来还没有人 向仓库提交过该文件的修改. 本地有未提交的修改, 于是执行 svn commit 将会成功地把修改提交到仓库中, 而 svn update 不会产生任何效果.

过时未修改的

文件在工作副本中未被修改, 但是在上一次更新之后有人往 仓库提交了该文件的修改. 为了让文件和最新版本保持同步, 应 该执行更新操作. 对文件执行 svn commit 不会产生任何效果, 执行 svn update 将 把仓库中的最新修改合并到文件中.

过时且已修改的

文件在本地工作副本和仓库都被修改了. 对文件执行 svn commit 会由于文件已过时而失败. 首先应该更新文件, 命令 svn update 试图 把仓库的修改合并到本地. 如果 Subversion 不能自动地以一种 合理的方式完成合并, 就会把冲突交由用户来解决.

仓库布局

大多数项目都有一条公认的开发 “主线”, 或者叫作 主干 (trunk); 还有一 些 分支 (branches), 分 支是某一条开发线的分叉; 还有一些 标签 (tags), 标签是某一条开发线的稳定版快照. 我们首先建议 每一个项目在仓库中都一个公认的 项目根目录 (project root), 目录中只存放和该项目相关的 数据. 然后, 我们建议每一个项目根目录下都有一个表示开发主线的 trunk 子目录, 存放所有分支的 branches 子目录, 存放所有标签的 tags 子目录. 如果仓库只存放单个项目, 那么仓库的根目录也可以作为项目根目录.

用户开始使用仓库是通过执行 检出 (checkout) 命令. 检出仓库中的目录将会在用户的 本地主机上创建一个该目录的工作副本

.svn 里有什么东西?

工作副本的顶层目录 — 1.7 版以前是每个目录及其子目录 — 都有一个用于管理的子目录 .svn. 通常情况下, 操作 系统的目录列表指令不会显示该目录, 但它是一个非常重要的目录, 无论用户 做什么操作, 都不能删除或修改其中的内容, Subversion 管理工作副本的信息 都存放在这个目录里.

Subversion 支持的特性与选项非常丰富, 但是能够在日常工作中用到的却很 少. 本节将介绍日常工作中最常用到的 Subversion 操作.

典型的工作周期就像:

更新工作副本. 这会用到命令 svn update.

修改.最常见的修改就是编辑已有文件的内容, 但有时还要添加, 删除, 复制和移动文件或目录 — 命令 svn add, svn delete, svn copy 和 svn move 负责 处理工作副本的结构性调整.

审核修改. 用命令 svn status 和 svn diff 查看工作副本发生了哪些变化.

修正错误. 人无完人, 在审核修改时用户可 能会发现某些修改是不正确的. 有时候修正错误最简单的方式是撤消所有的 修改, 重新开始. 命令 svn revert 可以把文件或目 录恢复到修改前的样子.

解决冲突 (合并其他人的修改). 当一个用户 正在修改文件时, 其他人可能已经把自己的修改提交到了服务器上. 为了防止 在提交修改时, 由于工作副本过旧导致提交失败, 用户需要把其他人的修改 更新到本地, 用到的命令是 svn update. 如果命令 的执行结果有冲突产生, 用户需要用命令 svn resolve 解决冲突.

发布 (提交) 修改. 命令 svn commit 把工作副本的修改提交到仓库中, 如果修改 被接受, 其他用户就可以看到这些修改.

用户可以使用命令 svn status 查看修改的整体概述, 用命令 svn diff 查看修改的细节.