subversion手册

Subversion简明手册

1. subversion基本概念

subversion是由包括原cvs开发者在内的一个开发组开发维护的，目的很明确，就是为了修复cvs的某些缺陷，添加一些有用的新特性。

从本地客户端连接到svn服务器有三种方式，本地访问方式、基于TCP/IP网络的HTTP方式、使用svn自带协议的svnserve方式。

2. svn工具组件

安装好svn后，有如下一些组件可用： svn 命令行客户端程序 svnversion 用来显示工作拷贝的状态(当前项目的修订版本) svnlook 直接查看subversion版本库的工具 svnadmin 建立、调整和修复subversion版本库的工具 svndumpfilter 过滤subversion版本库转储数据流的工具 mod_dav_svn Apache HTTP服务器的一个插件，使版本库可以通过网络访问 svnserve 一个单独运行的服务器程序，可以作为守护进程或由SSH调用。 svnsync 一个通过网络增量镜像版本库方式

3. 常用用法

使用svn的帮助： svn help 单个svn命令的帮助： svn help checkout

cs7902项目使用svnserve访问svn服务器，列出项目下所有文档的命令如下： # svn list svn://192.168.2.57/cs7902 doc/

mydroid/

svn-commit.tmp #

字符串svn://192.168.2.57/cs7902就是我们的版本库根路径。

使用subversion的典型工作周期如下：

? 更新你的工作拷贝

? svn update

? 做出修改

? svn add ? svn delete ? svn copy ? svn move

? 检验修改

? svn status ? svn diff

? 可能会取消一些修改

? svn revert

? 解决冲突（合并别人的修改）

? svn update ? svn resolved

? 提交你的修改

? svn commit

更新你的工作拷贝

更新你的工作拷与最新的版本同步。

$ svn update U foo.c U bar.c

Updated to revision 2.

服务器通过svn update将修改传递到你的工作拷贝时，每一个项目之前会有一个字母，来让你知道Subversion为保持最新对你的工作拷贝作了哪些工作。关于这些字母的详细含义如下： A 添加D 删除U 更新C 冲突G 合并

修改你的工作拷贝

可以使用的Subversion命令包括svn add、 svn delete、svn copy和svn move。如果只是修改版本库中已经存在的文件，在你提交之前，不必使用上面的任何一个命令。

可以对工作拷贝做出两种修改：文件修改和目录树修改。你不需要告诉Subversion你希望修改一个文件，只需要用你的编辑器、字处理器、图形程序或任 何工具做出修改，Subversion自动监测到文件的更改，此外，二进制文件的处理方式和文本文件一样—也有同样的效率。对于目录树更改，你可以告诉 Subversion将文件和目录预定的删除、添加、拷贝或移动标记，这些动作会在工作拷贝上立刻发生效果，但只有提交后才会在版本库里生效。

下面是Subversion用来修改目录树结构的五个子命令。 版本控制符号连接

在非Windows平台，Subversion可以将特殊类型符号链接（或是“symlink”）版本化，一个符号链接是对文件系统中其他对象的透明引用，可以通过对符合链接操作实现对引用对象的读写操作。 当符号链提交到Subversion版本库，Subversion会记住这个文件实际上是一个符号链，也会知道这个符号链指向的“对象”。 当这个符号链检出到另一个支持符号链的操作系统上时，Subversion会重新构建文件系统级的符号链接。当然这样不会影响在Windows这类不支持符号链的系统上，在此类系统上，Subversion只会创建一个包含指向对象路径的文本文件，因为这个文件不能在Windows系统上作为符号链使用，所以它也会防止Windows用户作其他Subversion相关的操作。 svn add foo

预定将文件、目录或者符号链foo添加到版本库，当你下次提交后，foo会成为其父目录的一个子对象。注意，如果foo是目录，所有foo中的内容也会预定添加进去，如果你只想添加foo本身，请使用--non-recursive (-N)参数。 svn delete foo

预定将文件、目录或者符号链foo从版本库中删除，如果foo是文件，它马上从工作拷贝中删除，如果是目录，不会被删除，但是Subversion准备好删除了，当你提交你的修改，foo就会在你的工作拷贝和版本库中被删除。[4]

svn copy foo bar

建立一个新的项目bar作为foo的复制品，会自动预定将bar添加，当在下次提交时会将bar添加到版本库，这种拷贝历史会记录下来（按照来自foo的方式记录），svn copy并不建立中介目录。 svn move foo bar

这个命令与与运行svn copy foo bar;svn delete foo完全相同，bar作为foo的拷贝准备添加，foo已经预定被删除，svn move不建立中介的目录。 svn mkdir blort

这个命令同运行 mkdir blort; svn add blort相同，也就是创建一个叫做blort的文件，并且预定添加到版本库。 不通过工作拷贝修改版本库

有一些情况下会立刻提交目录树的修改到版本库，这只发生在子命令直接操作URL，而不是工作拷贝路径时。以特定的方式使用svn mkdir、svn copy、svn move和svn delete可以针对URL操作（并且不要忘记svn import只针对URL操作）。

指定URL的操作方式有一些区别，因为在使用工作拷贝的运作方式时，工作拷贝成为一个“集结地”，可以在提交之前整理组织所要做的修改，直接对URL操作就没有这种奢侈，所以当你直接操作URL的时候，所有以上的动作代表一个立即的提交。 检查你的修改

当你完成修改，你需要提交他们到版本库，但是在此之前，检查一下做过什么修改是个好主意，通过提交前的检查，你可以整理一份精确的日志信息，你也可以发现你不小心修改的文件，给了你一次恢复修改的机会。此外，这是一个审查和仔细察看修改的好机会，你可通过命令svn status浏览所做的修改，通过svn diff检查修改的详细信息。

这三个命令（svn status、svn diff和svn revert）都可以在没有网络的情况下工作（假定你的版本库是通过网络而不是本地访问的），这让你在没有网络连接时的管理修改过程更加容易，像在飞机上旅行，乘坐火车往返或是在海滩上奋力工作时。[5]

Subversion通过在.svn管理区域使用原始的版本缓存来做到这一点，这使得报告和恢复本地修改而不必访问网络，这个缓存（叫做“text-base”）也允许Subversion可以根据原始版本生成一个压缩的增量（“区别”） 提交—即使你有个非常快的网络，有这样一个缓存有极大的好处，只向服务器提交修改的部分而不是整个文件。

Subversion已经被优化来帮助你完成这个任务，可以在不与版本库通讯的情况下做许多事情，详细来说，对于每一个文件，你的的工作拷贝在.svn包含了一个“原始的”拷贝，所以Subversion可以快速的告诉你那些文件修改了，甚至允许你在不与版本库通讯的情况下恢复修改。 查看你的修改概况

为了浏览修改的内容，你会使用这个svn status命令，在所有Subversion命令里，svn status可能会是你用的最多的命令。 CVS 用户：控制另类的更新！

你也许使用cvs update来看你做了哪些修改，svn status会给你所有你做的改变—而不需要访问版本库，并且不会在不知情的情况下与其他用户作的更改比较。

在Subversion，update只是做这件事—将工作拷贝更新到版本库的最新版本，你可以消除使用

update察看本地修改的习惯。

如果你在工作拷贝的顶级目录运行不带参数的svn status命令，它会检测你做的所有的文件或目录的修改，以下的例子是来展示svn status可能返回的状态码（注意，#之后的不是svn status打印的）。

A stuff/loot/bloo.h # file is scheduled for addition

C stuff/loot/lump.c # file has textual conflicts from an update D stuff/fish.c # file is scheduled for deletion

M bar.c # the content in bar.c has local modifications

在这种格式下，svn status打印6列字符，紧跟一些空格，接着是文件或者目录名。第一列告诉一个文件或目录的状态或它的内容，返回代码如下：

A item

预定加入到版本库的文件、目录或符号链的item。 C item

文件item发生冲突，在从服务器更新时与本地版本发生交迭，在你提交到版本库前，必须手工的解决冲突。 D item

文件、目录或是符号链item预定从版本库中删除。 M item

文件item的内容被修改了。

如果你传递一个路径给svn status，它只给你这个项目的信息：

$ svn status stuff/fish.c D stuff/fish.c

svn status也有一个--verbose (-v)选项，它可以显示工作拷贝中的所有项目，即使没有改变过的：

$ svn status -v

M 44 23 sally README 44 30 sally INSTALL M 44 20 harry bar.c 44 18 ira stuff

44 35 harry stuff/trout.c D 44 19 ira stuff/fish.c 44 21 sally stuff/things

A 0 ? ? stuff/things/bloo.h 44 36 harry stuff/things/gloo.c

这是svn status的“加长形式”，第一列保持相同，第二列显示一个工作版本号，第三和第四列显示最后一次修改的版本号和修改人（这些列不会与我们刚才提到的字符混淆）。

上面所有的svn status调用并没有联系版本库，只是与.svn中的原始数据进行比较的结果，最后，是--show-updates (-u)选项，它将会联系版本库为已经过时的数据添加新信息：

$ svn status -u -v

M * 44 23 sally README M 44 20 harry bar.c

* 44 35 harry stuff/trout.c D 44 19 ira stuff/fish.c

A 0 ? ? stuff/things/bloo.h Status against revision: 46

注意这两个星号：如果你现在执行svn update，你的README和trout.c会被更新，这告诉你许多有用的信息—你可以在提交之前，需要使用更新操作得到文件README的更新，或者说文件已经过时，版本库会拒绝了你的提交。（后面还有更多关于此主题）。

关于文件和目录，svn status可以比我们的展示显示更多的内容，完整的描述可以看svn status。 检查你的本地修改的详情

另一种检查修改的方式是svn diff命令，你可以通过不带参数的svn diff精确的找出你所做的修改，这会输出统一区别格式的区别信息：

$ svn diff Index: bar.c

=================================================================== --- bar.c (revision 3) +++ bar.c (working copy) @@ -1,7 +1,12 @@

+#include +#include +#include +

+#include

int main(void) {

- printf(\+ printf(\ return 0; }

Index: README

=================================================================== --- README (revision 3) +++ README (working copy) @@ -193,3 +193,4 @@

+Note to self: pick up laundry.

Index: stuff/fish.c

=================================================================== --- stuff/fish.c (revision 1) +++ stuff/fish.c (working copy) -Welcome to the file known as 'fish'. -Information on fish will be here soon.

Index: stuff/things/bloo.h

=================================================================== --- stuff/things/bloo.h (revision 8) +++ stuff/things/bloo.h (working copy)

+Here is a new file to describe +things about bloo.

svn diff命令通过比较你的文件和.svn的“原始”文件来输出信息，预定要增加的文件会显示所有增加的文本，要删除的文件会显示所有要删除的文本。

输出的格式为统一区别格式（unified diff format），删除的行前面加一个-，添加的行前面有一个+，svn diff命令也打印文件名和打补丁需要的信息，所以你可以通过重定向一个区别文件来生成“补丁”：

$ svn diff > patchfile

举个例子，你可以把补丁文件发送邮件到其他开发者，在提交之前审核和测试。

Subversion使用内置区别引擎，缺省情况下输出为统一区别格式。如果你期望不同的输出格式，你可以使用--diff-cmd指定外置的区别程序，并且通过--extensions传递其他参数，举个例子，察看本地文件foo.c的区别，同时忽略大小写差异，你可以运行svn diff --diff-cmd /usr/bin/diff --extensions '-bc' foo.c。 取消本地修改

假定我们在看svn diff的输出，你发现对某个文件的所有修改都是错误的，或许你根本不应该修改这个文件，或者是从开头重新修改会更加容易。

这是使用svn revert的好机会： $ svn revert README Reverted 'README'

Subversion把文件恢复到未修改的状态，叫做.svn目录的“原始”拷贝，应该知道svn revert可以恢复任何预定要做的操作，举个例子，你不再想添加一个文件：

$ svn status foo ? foo

$ svn add foo A foo

$ svn revert foo Reverted 'foo'

$ svn status foo ? foo

注意

svn revertITEM的效果与删除ITEM然后执行svn update -r BASEITEM完全一样，但是，如果你使用svn revert它不必通知版本库就可以恢复文件。 或许你不小心删除了一个文件： $ svn status README README

$ svn delete README D README

$ svn revert README Reverted 'README'

$ svn status README README

解决冲突（合并别人的修改）

我们可以使用svn status -u来预测冲突，当你运行svn update一些有趣的事情发生了： $ svn update U INSTALL G README C bar.c

Updated to revision 46.

U和G没必要关心，文件干净的接受了版本库的变化，文件标示为U表明本地没有修改，文件已经根据版本库更新。G标示合并，标示本地已经修改过，与版本库没有重迭的地方，已经合并。 但是C表示冲突，说明服务器上的改动同你的改动冲突了，你需要自己手工去解决。

当冲突发生了，有三件事可以帮助你注意到这种情况和解决问题：

? Subversion在更新时打印C标记，并且标记这个文件已冲突。

? 如果Subversion认为这个文件是可合并的，它会置入冲突标记—特殊的横线分开冲突的“两面”

—在文件里可视化的描述重叠的部分（Subversion使用svn:mime-type属性来决定一个文件是否可以使用上下文的，以行为基础的合并，更多信息可以看“文件内容类型”一节。）

? 对于每一个冲突的文件，Subversion放置三个额外的未版本化文件到你的工作拷贝：

filename.mine

你更新前的文件，没有冲突标志，只是你最新更改的内容。（如果Subversion认为这个文件不可以合并，.mine文件不会创建，因为它和工作文件相同。） filename.rOLDREV

这是你的做更新操作以前的BASE版本文件，就是你在上次更新之后未作更改的版本。 filename.rNEWREV

这是你的Subversion客户端从服务器刚刚收到的版本，这个文件对应版本库的HEAD版本。

这里OLDREV是你的.svn目录中的修订版本号，NEWREV是版本库中HEAD的版本号。

举一个例子，Sally修改了sandwich.txt，Harry刚刚改变了他的本地拷贝中的这个文件并且提交到服务器，Sally在提交之前更新它的工作拷贝得到了冲突： $ svn update C sandwich.txt

Updated to revision 2. $ ls -1

sandwich.txt

sandwich.txt.mine sandwich.txt.r1

sandwich.txt.r2

在这种情况下，Subversion不会允许你提交sandwich.txt，直到你的三个临时文件被删掉。 $ svn commit -m \svn: Commit failed (details follow):

svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict 如果你遇到冲突，三件事你可以选择：

? “手动”合并冲突文本（检查和修改文件中的冲突标志）。 ? 用某一个临时文件覆盖你的工作文件。

? 运行svn revert 来放弃所有的本地修改。

一旦你解决了冲突，你需要通过命令svn resolved让Subversion知道，这样就会删除三个临时文件，Subversion就不会认为这个文件是在冲突状态了。[6] $ svn resolved sandwich.txt

Resolved conflicted state of 'sandwich.txt'

手工合并冲突

第一次尝试解决冲突让人感觉很害怕，但经过一点训练，它简单的像是骑着车子下坡。

这里一个简单的例子，由于不良的交流，你和同事Sally，同时编辑了sandwich.txt。Sally提交了修改，当你准备更新你的工作拷贝，冲突发生了，我们不得不去修改sandwich.txt来解决这个问题。首先，看一下这个文件： $ cat sandwich.txt Top piece of bread Mayonnaise Lettuce Tomato Provolone

<<<<<<< .mine Salami

Mortadella Prosciutto ======= Sauerkraut

Grilled Chicken >>>>>>> .r2 Creole Mustard

Bottom piece of bread

小于号、等于号和大于号串是冲突标记，并不是冲突的数据，你一定要确定这些内容在下次提交之前得到删除，前两组标志中间的内容是你在冲突区所做的修改： <<<<<<< .mine Salami

Mortadella Prosciutto =======

后两组之间的是Sally提交的修改冲突：

======= Sauerkraut

Grilled Chicken >>>>>>> .r2

通常你并不希望只是删除冲突标志和Sally的修改—当她收到三明治时，会非常的吃惊。所以你应该走到她的办公室或是拿起电话告诉Sally，你没办法从从意大利熟食店得到想要的泡菜。[7]一旦你们确认了提交内容后，修改文件并且删除冲突标志。 Top piece of bread Mayonnaise Lettuce Tomato Provolone Salami

Mortadella Prosciutto

Creole Mustard

Bottom piece of bread

现在运行svn resolved，你已经准备好提交了：

$ svn resolved sandwich.txt

$ svn commit -m \

现在我们准备好提交修改了，注意svn resolved不像我们本章学过的其他命令一样需要参数，在任何你认为解决了冲突的时候，只需要小心运行svn resolved，—一旦删除了临时文件，Subversion会让你提交这文件，即使文件中还存在冲突标记。

记住，如果你修改冲突时感到混乱，你可以参考subversion生成的三个文件—包括你未作更新的文件。你也可以使用三方交互合并工具检验这三个文件。 复制文件到你的工作文件

如果你只是希望取消你的修改，你可以仅仅拷贝Subversion为你生成的文件替换你的工作拷贝： $ svn update C sandwich.txt

Updated to revision 2. $ ls sandwich.*

sandwich.txt sandwich.txt.mine sandwich.txt.r2 sandwich.txt.r1 $ cp sandwich.txt.r2 sandwich.txt $ svn resolved sandwich.txt

脚注：使用svn revert

如果你得到冲突，经过检查你决定取消自己的修改并且重新编辑，你可以恢复你的修改： $ svn revert sandwich.txt Reverted 'sandwich.txt' $ ls sandwich.* sandwich.txt

注意，当你恢复一个冲突的文件时，不需要再运行svn resolved。

提交你的修改

最后！你的修改结束了，你合并了服务器上所有的修改，你准备好提交修改到版本库。

svn commit命令发送所有的修改到版本库，当你提交修改时，你需要提供一些描述修改的日志信息，你的信息会附到这个修订版本上，如果信息很简短，你可以在命令行中使用--message（或-m）选项： $ svn commit -m \Sending sandwich.txt Transmitting file data . Committed revision 3.

然而，如果你把写日志信息当作工作的一部分，你也许会希望告诉Subversion通过一个文件名得到日志信息，使用--file选项： $ svn commit -F logmsg

Sending sandwich.txt Transmitting file data . Committed revision 4.

如果你没有指定--message或者--file选项，Subversion会自动地启动你最喜欢的编辑器（见“配置”一节的editor-cmd部分）来编辑日志信息。

提示

如果你使用编辑器撰写日志信息时希望取消提交，你可以直接关掉编辑器，不要保存，如果你已经做过保存，只要简单的删掉所有的文本并再次保存，然后退出。 $ svn commit

Waiting for Emacs...Done

Log message unchanged or not specified a)bort, c)ontinue, e)dit a $

版本库不知道也不关心你的修改作为一个整体是否有意义，它只检查是否有其他人修改了同一个文件，如果别人已经这样做了，你的整个提交会失败，并且提示你一个或多个文件已经过时了： $ svn commit -m \Sending rules.txt

svn: Commit failed (details follow):

svn: Your file or directory 'sandwich.txt' is probably out-of-date ?

（错误信息的精确措辞依赖于网络协议和你使用的服务器，但对于所有的情况，其思想完全一样。） 此刻，你需要运行svn update来处理所有的合并和冲突，然后再尝试提交。

我们已经覆盖了Subversion基本的工作周期，还有许多其它特性可以管理你得版本库和工作拷贝，但是只使用前面介绍的命令你就可以很进行日常工作了，我们还会覆盖更多用的还算频繁的命令。 检验历史

你的版本库就像是一台时间机器，它记录了所有提交的修改，允许你检查文件或目录以及相关元数据的历史。通过一个Subversion命令你可以根据时间或修订号取出一个过去的版本（或者恢复现在的工作拷贝），然而，有时候我们只是想看看历史而不想回到历史。

有许多命令可以为你提供版本库历史： svn log

展示给你主要信息：每个版本附加在版本上的作者与日期信息和所有路径修改。 svn diff

显示特定修改的行级详细信息。 svn cat

取得在特定版本的某一个文件显示在当前屏幕。 svn list

显示一个目录在某一版本存在的文件。

产生历史修改列表

找出一个文件或目录的历史信息，使用svn log命令，svn log将会提供你一条记录，包括：谁对文件或目录作了修改、哪个修订版本作了修改、修订版本的日期和时间、还有如果你当时提供了日志信息，也会显示。

$ svn log

------------------------------------------------------------------------ r3 | sally | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line

Added include lines and corrected # of cheese slices.

------------------------------------------------------------------------ r2 | harry | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line

Added main() methods.

------------------------------------------------------------------------ r1 | sally | Mon, 15 Jul 2002 17:40:08 -0500 | 1 line

Initial import

------------------------------------------------------------------------

注意日志信息缺省根据时间逆序排列，如果希望察看特定顺序的一段修订版本或者单一版本，使用--revision(-r) 选项：

$ svn log -r 5:19 # shows logs 5 through 19 in chronological order

$ svn log -r 19:5 # shows logs 5 through 19 in reverse order

$ svn log -r 8 # shows log for revision 8 你也可以检查单个文件或目录的日志历史，举个例子： $ svn log foo.c ?

$ svn log http://foo.com/svn/trunk/code/foo.c ?

这样只会显示这个工作文件（或者URL）做过修订的版本的日志信息。

如果你希望得到目录和文件更多的信息，你可以对svn log命令使用--verbose (-v)开关，因为

Subversion允许移动和复制文件和目录，所以跟踪路径修改非常重要，在详细模式下，svn log 输出中会包括一个路径修改的历史：

$ svn log -r 8 -v

------------------------------------------------------------------------ r8 | sally | 2002-07-14 08:15:29 -0500 | 1 line Changed paths:

M /trunk/code/foo.c M /trunk/code/bar.h

A /trunk/code/doc/README

Frozzled the sub-space winch.

------------------------------------------------------------------------

svn log也有一个--quiet (-q)选项，会禁止日志信息的主要部分，当与--verbose结合使用，仅会显示修改的文件名。

为什么svn log给我一个空的回应？

当使用Subversion一些时间后，许多用户会遇到这种情况：

$ svn log -r 2

------------------------------------------------------------------------ $

乍一看，好像是一个错误，但是想一下修订版本号是作用在版本库整体之上的，如果你没有提供路径，svn log会使用当前目录作为默认的目标，所以，作为结果，如果你对一个本身和子目录在指定版本到现在没有做过修改的目录运行这个命令，你会得到空的日志。如果你希望察看某个版本做的修改的日志，只需要直接告诉svn log使用版本库顶级的目录作为参数，例如svn log -r 2 http://svn.collab.net/repos/svn。 检查历史修改的详情

我们已经看过svn diff—使用标准区别文件格式显示区别，它在提交前用来显示本地工作拷贝与版本库的区别。

事实上，svn diff有三种不同的用法：

? 检查本地修改

? 比较工作拷贝与版本库 ? 比较版本库与版本库

比较本地修改

像我们看到的，不使用任何参数调用时，svn diff将会比较你的工作文件与缓存在.svn的“原始”拷贝：

$ svn diff

Index: rules.txt

=================================================================== --- rules.txt (revision 3) +++ rules.txt (working copy) @@ -1,4 +1,5 @@

Be kind to others

Freedom = Responsibility Everything in moderation -Chew with your mouth open +Chew with your mouth closed

+Listen when others are speaking $

比较工作拷贝和版本库

如果传递一个--revision（-r）参数，你的工作拷贝会与指定的版本比较。 $ svn diff -r 3 rules.txt Index: rules.txt

=================================================================== --- rules.txt (revision 3) +++ rules.txt (working copy) @@ -1,4 +1,5 @@ Be kind to others

Freedom = Responsibility Everything in moderation -Chew with your mouth open +Chew with your mouth closed

+Listen when others are speaking $

比较版本库与版本库

如果通过--revision （-r）传递两个通过冒号分开的版本号，这两个版本会进行比较。 $ svn diff -r 2:3 rules.txt Index: rules.txt

=================================================================== --- rules.txt (revision 2) +++ rules.txt (revision 3) @@ -1,4 +1,4 @@ Be kind to others

-Freedom = Chocolate Ice Cream +Freedom = Responsibility Everything in moderation Chew with your mouth open $

与前一个修订版本比较更方便的办法是使用--change (-c)：

$ svn diff -c 3 rules.txt Index: rules.txt

=================================================================== --- rules.txt (revision 2) +++ rules.txt (revision 3) @@ -1,4 +1,4 @@ Be kind to others

-Freedom = Chocolate Ice Cream +Freedom = Responsibility

Everything in moderation Chew with your mouth open $

最后，即使你在本机没有工作拷贝，还是可以比较版本库的修订版本，只需要在命令行中输入合适的URL：

$ svn diff -c 5 http://svn.example.com/repos/example/trunk/text/rules.txt ? $

浏览版本库

通过svn cat和svn list，你可以在未修改工作修订版本的情况下查看文件和目录的内容，实际上，你甚至也不需要有一个工作拷贝。 svn cat

如果你只是希望检查一个过去的版本而不希望察看它们的区别，使用svn cat： $ svn cat -r 2 rules.txt Be kind to others

Freedom = Chocolate Ice Cream Everything in moderation Chew with your mouth open $

你可以重定向输出到一个文件：

$ svn cat -r 2 rules.txt > rules.txt.v2 $

svn list

svn list可以在不下载文件到本地目录的情况下来察看目录中的文件： $ svn list http://svn.collab.net/repos/svn README branches/ clients/ tags/ trunk/

如果你希望察看详细信息，你可以使用--verbose(-v) 参数：

$ svn list -v http://svn.collab.net/repos/svn

20620 harry 1084 Jul 13 2006 README 23339 harry Feb 04 01:40 branches/

21282 sally Aug 27 09:41 developer-resources/ 23198 harry Jan 23 17:17 tags/ 23351 sally Feb 05 13:26 trunk/

这些列告诉你文件和目录最后修改的修订版本、做出修改的用户、如果是文件还会有文件的大小，最后是修改日期和项目的名字。

警告

没有任何参数的svn list命令缺省使用当前工作拷贝的版本库URL，而不是本地工作拷贝的目录。毕竟，如果你希望列出本地目录，你只需要使用ls（或任何合理的非UNIX等价物）。

获得旧的版本库快照

除了以上的命令，你可以使用带参数--revision的svn update和svn checkout来使整个工作拷贝“回到过去”[8]：

$ svn checkout -r 1729 # Checks out a new working copy at r1729 ?

$ svn update -r 1729 # Updates an existing working copy to r1729 ?

提示

许多Subversion新手使用前面的svn update实例来“回退”修改，但是你不能提交修改，你获得有新修订版本的过时工作拷贝也是没有用的。关于如何“回退”，我们可以看“找回删除的项目”一节。

最后，如果你构建了一个版本，并且希望从Subversion打包文件，但是你不希望有讨厌的.svn目录，这时你可以导出版本库的一部分文件而没有.svn目录。就像svn update和svn checkout，你也可以传递--revision选项给svn export：

$ svn export http://svn.example.com/svn/repos1 # Exports latest revision ?

$ svn export http://svn.example.com/svn/repos1 -r 1729 # Exports revision r1729 ?

有时你只需要清理

当Subversion改变你的工作拷贝（或是.svn中 的任何信息），它会尽可能的小心，在修改任何事情之前，它把意图写到日志文件中去，然后执行log文件中的命令，并且执行过程中在工作拷贝的相关部分保存 一个锁— 防止Subversion客户端在变更过程中访问工作拷贝。然后删掉日志文件，这与记帐试的文件系统架构类似。如果Subversion的操作中断了（举 个例子：进程被杀死了，机器死掉了），日志文件会保存在硬盘上，通过重新执行日志文件，Subversion可以完成上一次开始的操作，你的工作拷贝可以 回到一致的状态。

这就是svn cleanup所作的：它查找工作拷贝中的所有遗留的日志文件，删除进程中工作拷贝的锁。如果Subversion告诉你工作拷贝中的一部分已经“锁定”了，你就需要运行这个命令了。同样，svn status将会使用L 标示锁定的项目： $ svn status L somedir

M somedir/foo.c

$ svn cleanup $ svn status

M somedir/foo.c

不要将工作拷贝锁与Subversion用户使用并发版本控制的“锁定-修改-解锁”模型创建的锁混淆；更多细节见“锁定”的三种含义。

总结

我们已经覆盖了大多数Subversion的客户端命令，引人注目的例外是处理分支与合并（见第 4 章 分支与合并）以及属性（见“属性”一节）的命令，然而你也许会希望跳到第 9 章 Subversion 完全参考来察看所有不同的命令—怎样利用它们使你的工作更容易。

创建SVN服务器过程

1.添加用户组subversion,将自己添加到该组

2.创建svn根目录和cs7902项目子目录，修改相应的权限

mkdir /root/subversion

cd /root/subversion

mkdir /subversion/cs7902

chown -R root:subversion cs7902

chmod -R g+rws cs7902

3.创建版本库

svnadmin create /root/subversion/cs7902

4.修改/root/subversion/cs7902/conf/svnserve.conf来配置其访问控制。

取消下面的注释符号来设置授权机制：

# [general]

# password-db = passwd

在“passwd”文件中维护用户清单。编辑同一目录下“passwd”文件，添加新用户。语法如下：

username = password

5.将下面的启动命令添加到/etc/rc.local中，启动ubuntu即启动subversion

svnserve -d --foreground -r /root/subversion

本文来源：https://www.bwwdw.com/article/qka3.html