svn学习笔记
推荐的版本库布局
尽管Subversion的灵活性允许你自由布局版本库，但我们有一套推荐的方式，创建一个trunk目录来保存开发的“主线”，一个branches目录存放分支拷贝，tags目录保存标签拷贝，例如：
$ svn list file:///usr/local/svn/repos
/trunk
/branches
/tags
因为你的工作拷贝“同你系统上的文件和目录没有任何区别”，你可以随意修改文件，但是你必须告诉Subversion你做的其他任何事。例如，你希望拷贝或移动工作拷贝的一个文件，你应该使用svn copy或者 svn move而不要使用操作系统的拷贝移动命令
.svn目录包含什么？
工作拷贝中的任何一个目录包括一个名为.svn管理区域，通常列表操作不显示这个目录，但它仍然是一个非常重要的目录，无论你做什么？不要删除或是更改这个管理区域的任何东西，Subversion使用它来管理工作拷贝。如果你不小心删除了子目录.svn，最简单的解决办法是删除包含的目录（普通的文件系统删除，而不是svn delete），然后在父目录运行svn update，Subversion客户端会重新下载你删除的目录，并包含新的.svn。
禁用密码缓存
当你执行的Subversion命令需要认证时，缺省情况下Subversion会在磁盘缓存认证信息，这样做出于便利，在接下来的操作中你就可以不必输入密码，但如果你很在乎密码缓存，[3]你可以永久关闭缓存或每次执行命令时说明。在某次命令关闭密码缓存可以在命令中使用--no-auth-cache选项，如果希望永久关闭缓存，可以在本机的Subversion配置文件中添加store-passwords = no这一行。
用其它身份认证
因为Subversion认证缓存是缺省设置（包含用户名和密码），用来记住上一次修改工作拷贝的人非常方便。但是有时候会不好用—特别是如果你使用的是共享工作拷贝，在这种情况下，你只需要为命令行传递--username选项，Subversion就会尝试使用该用户认证，如果需要也提示你输入密码。
典型的工作周期是这样的：
更新你的工作拷贝
svn update
做出修改
svn add
svn delete
svn copy
svn move
检验修改
svn status
svn diff
可能会取消一些修改
svn revert
解决冲突（合并别人的修改）
svn update
svn resolved
提交你的修改
svn commit
修改你的工作拷贝
svn add foo
预定将文件、目录或者符号链foo添加到版本库，当你下次提交后，foo会成为其父目录的一个子对象。注意，如果foo是目录，所有foo中的内容也会预定添加进去，如果你只想添加foo本身，请使用--non-recursive (-N)参数。
svn delete foo
预定将文件、目录或者符号链foo从版本库中删除，如果foo是文件，它马上从工作拷贝中删除，如果是目录，不会被删除，但是Subversion准备好删除了，当你提交你的修改，foo就会在你的工作拷贝和版本库中被删除。
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的文件，并且预定添加到版本库。
查看你的修改概况
svn status打印6列字符，紧跟一些空格，接着是文件或者目录名。第一列告诉一个文件或目录的状态或它的内容，返回代码如下：
A item
预定加入到版本库的文件、目录或符号链的item。
C item
文件item发生冲突，在从服务器更新时与本地版本发生交迭，在你提交到版本库前，必须手工的解决冲突。
D item
文件、目录或是符号链item预定从版本库中删除。
M item
文件item的内容被修改了。
svn status也有一个--verbose (-v)选项，它可以显示工作拷贝中的所有项目，即使没有改变过的
上面所有的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 diff命令，你可以通过不带参数的svn diff精确的找出你所做的修改
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 revert ITEM的效果与删除ITEM然后执行svn update -r BASEITEM完全一样，但是，如果你使用svn revert它不必通知版本库就可以恢复文件。
解决冲突（合并别人的修改）
我们可以使用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 "Add a few more things"
svn: Commit failed (details follow):
svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict
如果你遇到冲突，三件事你可以选择：
“手动”合并冲突文本（检查和修改文件中的冲突标志）。
用某一个临时文件覆盖你的工作文件。
运行svn revert 来放弃所有的本地修改。
一旦你解决了冲突，你需要通过命令svn resolved让Subversion知道，这样就会删除三个临时文件，Subversion就不会认为这个文件是在冲突状态了。
$ 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 "Go ahead and use my sandwich, discarding Sally's edits."
现在我们准备好提交修改了，注意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 "Corrected number of cheese slices."
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会自动地启动你最喜欢的编辑器来编辑日志信息。
检验历史
你的版本库就像是一台时间机器，它记录了所有提交的修改，允许你检查文件或目录以及相关元数据的历史。通过一个Subversion命令你可以根据时间或修订号取出一个过去的版本（或者恢复现在的工作拷贝），然而，有时候我们只是想看看历史而不想回到历史。
有许多命令可以为你提供版本库历史：
svn log
展示给你主要信息：每个版本附加在版本上的作者与日期信息和所有路径修改。
svn diff
显示特定修改的行级详细信息。
svn cat
取得在特定版本的某一个文件显示在当前屏幕。
svn list
显示一个目录在某一版本存在的文件。
比较本地修改:像我们看到的，不使用任何参数调用时，svn diff将会比较你的工作文件与缓存在.svn的“原始”拷贝
比较工作拷贝和版本库:如果传递一个--revision（-r）参数，你的工作拷贝会与指定的版本比较 : svn diff -r 3 rules.txt
比较版本库与版本库:如果通过--revision （-r）传递两个通过冒号分开的版本号，这两个版本会进行比较 : svn diff -r 2:3 rules.txt 。与前一个修订版本比较更方便的办法是使用--change (-c) : svn diff -c 3 rules.txt
浏览版本库
通过svn cat和svn list，你可以在未修改工作修订版本的情况下查看文件和目录的内容，实际上，你甚至也不需要有一个工作拷贝。
svn cat
如果你只是希望检查一个过去的版本而不希望察看它们的区别，使用svn cat
svn list
可以在不下载文件到本地目录的情况下来察看目录中的文件,如果你希望察看详细信息，你可以使用--verbose(-v) 参数
没有任何参数的svn list命令缺省使用当前工作拷贝的版本库URL，而不是本地工作拷贝的目录。毕竟，如果你希望列出本地目录，你只需要使用ls（或任何合理的非UNIX等价物）。
获得旧的版本库快照
除了以上的命令，你可以使用带参数--revision的svn update和svn checkout来使整个工作拷贝“回到过去”：
$ 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目录，这时你可以导出版本库的一部分文件而没有.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客户端可以理解一些修订版本关键字，这些关键字可以用来代替--revision (r)的数字参数，这会被Subversion解释到特定修订版本号：
HEAD
版本库中最新的（或者是“最年轻的”）版本。
BASE
工作拷贝中一个条目的修订版本号，如果这个版本在本地修改了，则“BASE版本”就是这个条目在本地未修改的版本。
COMMITTED
项目最近修改的修订版本，与BASE相同或更早。
PREV
一个项目最后修改版本之前的那个版本，技术上可以认为是COMMITTED -1。
因为可以从描述中得到，关键字PREV，BASE和COMMITTED只在引用工作拷贝路径时使用，而不能用于版本库URL，而关键字HEAD则可以用于两种路径类型。
下面是一些修订版本关键字的例子：
$ svn diff -r PREV:COMMITTED foo.c
# shows the last change committed to foo.c
$ svn log -r HEAD
# shows log message for the latest repository commit
$ svn diff -r HEAD
# compares your working copy (with all of its local changes) to the latest version of that tree in the repository
$ svn diff -r BASE:HEAD foo.c
# compares the unmodified version of foo.c with the latest version of foo.c in the repository
$ svn log -r BASE:HEAD
# shows all commit logs for the current versioned directory since you last updated
$ svn update -r PREV foo.c
# rewinds the last change on foo.c, decreasing foo.c's working revision
$ svn diff -r BASE:14 foo.c
# compares the unmodified version of foo.c with the way foo.c looked in revision 14
版本日期
在版本控制系统以外，修订版本号码是没有意义的，但是有时候你需要将时间和历史修订版本号关联。为此，--revision (-r)选项接受使用花括号（{和}）包裹的日期输入，Subversion支持标准ISO-8601日期和时间格式，也支持一些其他的。下面是一些例子。（记住使用引号括起所有包含空格的日期。）
$ svn checkout -r {2006-02-17}
$ svn checkout -r {15:30}
$ svn checkout -r {15:30:00.200000}
$ svn checkout -r {"2006-02-17 15:30"}
$ svn checkout -r {"2006-02-17 15:30 +0230"}
$ svn checkout -r {2006-02-17T15:30}
$ svn checkout -r {2006-02-17T15:30Z}
$ svn checkout -r {2006-02-17T15:30-04:00}
$ svn checkout -r {20060217T1530}
$ svn checkout -r {20060217T1530Z}
$ svn checkout -r {20060217T1530-0500}
当你指定一个日期，Subversion会在版本库找到接近这个日期的最近版本，并且对这个版本继续操作
Subversion 会早一天吗？
如果你只是指定了日期而没有时间（举个例子2006-11-27），你也许会以为Subversion会给你11-27号最后的版本，相反，你会得到一个26号版本，甚至更早。记住Subversion会根据你的日期找到最新的版本，如果你给一个日期，而没有给时间，像2006-11-27，Subversion会假定时间是00:00:00，所以在27号找不到任何版本。
如果你希望查询包括27号，你既可以使用（{"2006-11-27 23:59"}），或是直接使用第二天（{2006-11-28}）。
你可以使用时间段，Subversion会找到这段时间的所有版本：
$ svn log -r {2006-11-20}:{2006-11-29}
因为一个版本的时间戳是作为一个属性存储的—不是版本化的，而是可以编辑的属性—版本号的时间戳可以被修改，从而建立一个虚假的年代表，也可以被完全删除。Subversion正确转化修订版本日期到修订版本的能力依赖于修订版本时间戳顺序排列—修订版本越年轻，则时间戳越年轻。如果顺序没有被维护，你会发现使用日期指定修订版本不会返回你期望的数据。
忽略未版本控制的条目
在任何工作拷贝，将版本化文件和目录与没有也不准备版本化的文件分开会是非常常见的情况。文本编辑器的备份文件会将目录搞乱，代码编译过程中生成的中间文件，甚至最终文件也不是你希望版本化的，用户在见到这些文件和目录（经常是版本控制工作拷贝中）的任何时候都会将他们删除。
期望让Subversion的工作拷贝摆脱混乱保持干净是可笑的，实际上Subversion将工作拷贝是普通目录作为它的一项特性。但是这些没有版本化的文件和目录会给Subversion用户带来一些烦恼，例如，因为svn add和svn import命令都是会递归执行的，并不知道哪些文件你不希望版本化，很容易意外的添加一些文件。因为svn status会报告工作拷贝中包括未版本化文件和目录的信息，如果这种文件很多，它的输出会变得非常嘈杂。
所以Subversion提供了两种方法让你指明哪些文件可以被漠视，一种方法需要你修改Subversion的运行配置系统（见“运行配置区”一节），这样会使所有的Subversion操作都利用这个配置，通常来说，这是在某一个计算机上的操作，或者是某个计算机某个用户的操作。另一种方法利用了Subversion目录属性支持，与版本化的目录树紧密结合，因而会影响所有拥有这个目录树工作拷贝的人。两种机制都使用文件模式。
Subversion运行配置系统提供一个global-ignores选项，其中的值是空格分开的文件名模式（或glob）。这些模式会应用到可以添加到版本控制的候选者，也就是svn status显示出来的未版本化文件。如果文件名与其中的某个模式匹配，Subversion会当这个文件不存在。这个文件模式最好是全局不期望版本化的模式，例如编辑器Emacs的备份文件*~和.*~。
如果是在版本化目录上发现svn:ignore属性，其内容是一列以行分割的文件模式，Subversion用来判断在这个目录下对象是否被忽略。这些模式不会覆盖在运行配置设置的全局忽略，而是向其添加忽略模式。不像全局忽略选项，在svn:ignore属性中设置的值只会应用到其设置的目录，而不会应用到其子目录。svn:ignore属性是告诉Subversion在每个用户的工作拷贝对应目录忽略相同的文件的好方法，例如编译输出或—使用一个本书相关的例子—本书从DocBook XML文件生成的HTML、PDF或PostScript。
Subversion对于忽略文件模式的支持仅限于将未版本化文件和目录添加到版本控制时，如果一个文件已经在Subversion控制下，忽略模式机制不会再有效果，不要期望Subversion会阻止你提交一个符合忽略条件的修改—Subversion一直认为它是版本化的对象。
全局忽略模式只是一种个人喜好，可能更接近于用户的特定工具链，而不是特定工作拷贝的需要，所以余下的小节将关注svn:ignore属性和它的使用。
假定你的svn status有如下输出：
$ svn status calc
M calc/button.c
? calc/calculator
? calc/data.c
? calc/debug_log
? calc/debug_log.1
? calc/debug_log.2.gz
? calc/debug_log.3.gz
在这个例子里，你对button.c文件作了一些属性修改，但是你的工作拷贝也有一些未版本化的文件：你从源代码编译的最新计算器程序，一系列调试输出日志文件，现在你知道你的编译系统一直会编译生成计算器程序。 [13]而且你知道你的测试组件总是会留下这些调试日志，这对所有的工作拷贝都是一样的，不仅仅是你的。你也知道你不会有兴趣在svn status命令中显示这些信息，所以使用svn propedit svn:ignore calc来为calc目录增加一些忽略模式，举个例子，你或许会添加如下的值作为svn:ignore的属性：
calculator
debug_log*
当你添加完这些属性，你会在calc目录有一个本地修改，但是注意你的svn status输出有什么其他的不同：
$ svn status
M calc
M calc/button.c
? calc/data.c
现在，所有多余的输出不见了！当然，你的计算器程序和所有的日志文件还在工作拷贝中，Subversion仅仅是不再提醒你它们的存在和未版本化。现在所有讨厌的噪音都已经不再显示，只留下了你感兴趣的条目—如你忘记添加到版本控制的源代码文件data.c。
当然，不仅仅只有这种简略的工作拷贝状态输出，如果想查看被忽略的文件，可以使用Subversion的--no-ignore选项：
$ svn status --no-ignore
M calc
M calc/button.c
I calc/calculator
? calc/data.c
I calc/debug_log
I calc/debug_log.1
I calc/debug_log.2.gz
I calc/debug_log.3.gz
我们在前面提到过，svn add和svn import也会使用这个忽略模式列表，这两个操作都包括了询问Subversion来开始管理一组文件和目录。比强制用户挑拣目录树中那个文件要纳入版本控制的方式更好，Subversion使用忽略模式来检测那个文件不应该在大的迭代添加和导入操作中进入版本控制系统。再次说明，操作Subversion文件和目录时你可以使用--no-ignore选项忽略这个忽略列表。
关键字替换
Subversion具备添加关键字的能力—一些有用的，关于版本化的文件动态信息的片断—不必直接添加到文件本身。关键字通常会用来描述文件最后一次修改的一些信息，因为这些信息每次都有改变，更重要的一点，这是在文件修改之后，除了版本控制系统，对于任何企图保持数据最新的过程都是一场混乱，
举个例子，你有一个文档希望显示最后修改的日期，你需要麻烦每个作者提交之前做这件事情，也要修改文档的一部分来描述何时作的修改，但是迟早会有人忘记做这件事，不选择简单的告诉Subversion来执行替换LastChangedDate关键字的操作，你通过在目标位置放置一个keyword anchor来控制关键字插入的位置，这个anchor只是一个格式为$KeywordName$字符串。
所有作为anchor出现在文件里的关键字是大小写敏感的：为了关键字的扩展，你必须使用正确的大写，你必须考虑svn:keywords的属性值也是大小写敏感—特定的关键字名会忽略大小写，但是这个特性已经被废弃了。
Subversion定义了用来替换的关键字列表，这个列表保存了如下五个关键字，有一些也包括了可用的别名：
Date
这个关键字保存了文件最后一次在版本库修改的日期，看起来类似于$Date: 2006-07-22 21:42:37 -0700 (Sat, 22 Jul 2006) $，它也可以用LastChangedDate来指定。
Revision
这个关键字描述了这个文件最后一次修改的修订版本，看起来像$Revision: 144 $，也可以通过LastChangedRevision或者Rev引用。
Author
这个关键字描述了最后一个修改这个文件的用户，看起来类似$Author: harry $，也可以用LastChangedBy来指定。
HeadURL
这个关键字描述了这个文件在版本库最新版本的完全URL，看起来类似$HeadURL: http://svn.collab.net/repos/trunk/README $，可以缩写为URL。
Id
这个关键字是其他关键字一个压缩组合，它看起来就像$Id: calc.c 148 2006-07-28 21:30:43Z sally $，可以解释为文件calc.c上一次修改的修订版本号是148，时间是2006年7月28日，作者是sally。
前面的一些描述使用了类似“最后已知的”短语，请记住关键字扩展是客户端操作，你的客户端只“知道”在你更新工作拷贝时版本库发生的修改，如果你从不更新工作拷贝，即使文件在版本库里有规律的修改，这些关键字也不会扩展为不同的值。只在你的文件增加关键字anchor不会做什么特别的事情，Subversion不会尝试对你的文件内容执行文本替换，除非明确的被告知这样做，毕竟，你可以撰写一个关于如何使用关键字的文档，你不希望Subversion会替换你漂亮的关于不需要替换的关键字anchor实例！
为了告诉Subversion是否替代某个文件的关键字，我们要再次求助于属性相关的子命令，当svn:keywords属性设置到一个版本化的文件，这些属性控制了哪些关键字将会替换到这个文件，这个属性的值是空格分隔的前面列表的名称或是别名列表。
举个例子，假定你有一个版本化的文件weather.txt，内容如下：
Here is the latest report from the front lines.
$LastChangedDate$
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.
当没有svn:keywords属性设置到这个文件，Subversion不会有任何特别操作，现在让我们允许LastChangedDate关键字的替换。
$ svn propset svn:keywords "Date Author" weather.txt
property 'svn:keywords' set on 'weather.txt'
$
现在你已经对weather.txt的属性作了修改，你会看到文件的内容没有改变（除非你之前做了一些属性设置），注意这个文件包含了Rev的关键字anchor，但我们没有在属性值中包括这个关键字，Subversion会高兴的忽略替换这个文件中的关键字，也不会替换svn:keywords属性中没有出现的关键字。
在你提交了属性修改后，Subversion会立刻更新你的工作文件为新的替代文本，你将无法找到$LastChangedDate$的关键字anchor，你会看到替换的结果，这个结果也保存了关键字的名字，与美元符号（$）绑定在一起，而且我们预测的，Rev关键字不会被替换，因为我们没有要求这样做。
注意我们设置svn:keywords属性为“Date Author”，关键字anchor使用别名$LastChangedDate$并且正确的扩展。
Here is the latest report from the front lines.
$LastChangedDate: 2006-07-22 21:42:37 -0700 (Sat, 22 Jul 2006) $
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.
如果有其他人提交了weather.txt的修改，你的此文件的拷贝还会显示同样的替换关键字值—直到你更新你的工作拷贝，此时你的weather.txt重的关键字将会被替换来反映最新的提交信息。
Subversion 1.2引入了另一种关键字的语法，提供了额外和有用的，尽管是非典型的功能。你现在可以告诉Subversion为替代的关键字维护一个固定长度（从消耗字节的观点），通过在关键字名后使用双冒号（::），然后紧跟一组空格，你就定义了固定宽度。当Subversion使用替代值代替你的关键字，只会替换这些空白字符，保持关键字字段长度保持不变，如果替代值比定义的字段短，会有替代字段后保留空格；如果替代值太长，就会在最后的美元符号终止符前用井号（#）截断。
$Rev:: $: Revision of last commit
$Author:: $: Author of last commit
$Date:: $: Date of last commit
需要意识到，因为关键字字段的长度是以字节为单位，可能会破坏多字节值，例如一个用户名包含多字节的UTF-8字符，可能会遭遇从某个字符中间截断的情况，从字节角度看仅仅是一种截断，但是从UTF-8字符串角度看可能是错误和曲解的，当载入文件时，破坏的UTF-8文本可能导致整个文件的破坏，整个文件无法操作。所以，当限制关键字为固定大小时，需要选择一个可以扩展的大小。
锁定
Subversion 的锁定特性为两个主要目的服务：
1.顺序访问资源。允许用户得到一个排他的修改文件权，这个用户可以确定不可合并的修改不会被浪费—他对这个修改的提交会成功。
2.辅助交流。通过要求用户对某个版本化对象串行工作，用户可以知道对象正在被别人修改，这样可以防止浪费精力和时间去修改一个不可合并和提交的对象。
“锁定”的三种含义
在本小节，和几乎本书的每一个地方“lock”和“locking”描述了一种避免用户之间冲突提交的排他机制，但是佷不幸，Subversion中还有另外两种锁，因此需要在本书格外关心。
第一种是工作拷贝锁，Subversion内部用来防止不同客户端同时操作同一份工作拷贝的锁，这种锁使用svn status输出中第三列出现的L表示，可以使用svn cleanup删除，“有时你只需要清理”一节有介绍。
第二种，数据库锁，在Berkeley DB后端内部使用，防止多个程序访问数据库发生冲突，一个导致版本库“楔住”的错误发生后产生，“Berkeley DB 恢复”一节有描述。
在发生问题之前你完全可以忘记上面两种锁，在本书，“锁定”意味着第一种锁，除非是在从上下文中十分明确或明确指出的。
创建锁定
为了防止其他用户此时提交这个文件的修改（也是警告别人他正在修改它），使用svn lock命令锁定了版本库中的这个文件： $ svn lock banana.jpg -m "Editing file for tomorrow's release."
令牌的一个重要事实—它们缓存在工作拷贝。有锁定令牌是非常重要的，这给了工作拷贝权利利用这个锁的能力。svn status会在文件后面显示一个K（locKed的缩写），表明了拥有锁定令牌。
关于锁定令牌
一个锁不是一个认证令牌，而是一个授权令牌，这个令牌不是一个受保护的秘密，事实上，任何人都可以通过svn info URL发现这个唯一令牌。一个锁定令牌只有在工作拷贝中才有特别的意义，它是锁定建立在这个工作拷贝的证据，而不是其它用户在其他地方，仅仅检验锁定拥有者还不能防止出现意外。
例如，你在办公室电脑上锁定了一个文件，或许修改正在进行中。很有可能在你的家用计算机上的一个工作拷贝（或别的Subversion客户端）里你又不小心修改了同一个文件，仅仅因为检验了你就是锁定的拥有者。换句话说，锁定令牌防止你通过一个Subversion相关软件的工作破坏另一个的工作。（在我们的例子里，如果你真的需要在另一个工作拷贝修改这个文件，你必须打破锁定再重新锁定文件。）
需要注意到提交之后，svn status显示工作拷贝已经没有锁定令牌了，这是svn commit的标准行为方式—它会遍历工作拷贝（或者从目标列表，如果有列表的话），并且作为提交的一部分发送所有遇到的锁定令牌到服务器。当提交完全成功，前面用到的所有版本库锁定都会被释放—即使是没有提交的文件。这样的原因是不鼓励用户滥用锁定，或者是长时间的保持锁定。
自动释放锁定的特性可以通过svn commit的--no-unlock选项关闭，当你要提交文件，同时期望继续修改而必须保留锁定时非常有用。这个特性也可以半永久性的设定，方法是设置运行中config文件（见“运行配置区”一节）的no-unlock = yes。
当然，锁定一个文件不会强制一个人要提交修改，任何时候都可以通过运行svn unlock命令释放锁定
发现锁定
最明显的方式就是因为锁定而不能提交一个文件，最简单的方式是svn status --show-updates
$ svn status -u
M 23 bar.c
M O 32 raisin.jpg
* 72 foo.h
Status against revision: 105
在这个例子里，Sally可以见到不仅她的foo.h是过期的，而且发现两个计划要提交的文件被锁定了。O符号表示其他人所订了文件。如果她尝试提交，raisin.jpg的锁定会阻止她，Sally会纳闷谁锁定了文件，什么时候，为什么。再一次，svn info拥有答案：
$ svn info http://svn.example.com/repos/project/raisin.jpg
Path: raisin.jpg
Name: raisin.jpg
URL: http://svn.example.com/repos/project/raisin.jpg
Repository UUID: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Revision: 105
Node Kind: file
Last Changed Author: sally
Last Changed Rev: 32
Last Changed Date: 2006-01-25 12:43:04 -0600 (Sun, 25 Jan 2006)
Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Lock Owner: harry
Lock Created: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Lock Comment (1 line):
Need to make a quick tweak to this p_w_picpath.
解除和偷窃锁定
版本库锁定并不是神圣不可侵犯的，在Subversion的缺省配置状态，不只是创建者可以释放锁定，任何人都可以。当有其他人期望消灭锁定时，我们称之为打破锁定。
从管理员的位子上很容易打破锁定，svnlook和svnadmin程序都有能力从版本库直接显示和删除锁定。
svnadmin lslocks /usr/local/svn/repos
svnadmin rmlocks /usr/local/svn/repos /project/raisin.jpg
更有趣的选项是允许用户互相打破锁定，为此，Sally只需要使用unlock命令的--force选项：
$ svn status -u
M 23 bar.c
M O 32 raisin.jpg
* 72 foo.h
Status against revision: 105
$ svn unlock raisin.jpg
svn: 'raisin.jpg' is not locked in this working copy
$ svn info raisin.jpg | grep URL
URL: http://svn.example.com/repos/project/raisin.jpg
$ svn unlock http://svn.example.com/repos/project/raisin.jpg
svn: Unlock request failed: 403 Forbidden (http://svn.example.com)
$ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
'raisin.jpg' unlocked.
当然，简单的打破锁定也许还不够，在这个例子里，Sally不仅想要打破Harry遗忘的锁定，她也希望自己重新锁定。她可以通过运行svn unlock --force紧接着svn lock，但是有可能有人在这两次命令之间锁定了文件，最简单的方式是窃取这个锁定，将打破和重新锁定变成一种原子操作，为此需要运行svn lock加--force选项
如果版本库锁定被打破了，svn status --show-updates会在文件旁边显示一个B (Broken)。如果有一个新的锁，就会显示一个T (sTolen)符号。最终，svn update会注意到所有死掉的锁定并且把它们从工作拷贝中删除掉。
锁定交流
利用svn lock和svn unlock来创建、释放、打破和窃取锁定，这就满足了顺序访问文件的要求，但是浪费时间
例如，假定Harry锁定了一个图片，并开始编辑。同时，几英里之外的Sally希望做同样的工作，她没想到运行svn status --show-updates，她不知道Harry已经锁定了文件。她花费了数小时来修改文件，当她真被提交时发现文件已经被锁定或者是她的文件已经过期了。她的修改不能和Harry的合并，他们中的一人需要抛弃自己的工作，许多时间被浪费了。
Subversion针对此问题的解决方案是提供一种机制，提醒用户在开始编辑以前必须锁定这个文件，这个机制就是提供一种特别的属性--svn:needs-lock。当有这个值时，除非用户锁定这个文件，否则文件一直是只读的。当得到一个锁定令牌（运行svn lock的结果），文件变成可读写，当释放这个锁后，文件又变成只读。
$ /usr/local/bin/gimp raisin.jpg
gimp: error: file is read-only!
$ ls -l raisin.jpg
-r--r--r-- 1 sally sally 215589 Jun 8 19:23 raisin.jpg
$ svn lock raisin.jpg
svn: Lock request failed: 423 Locked (http://svn.example.com)
$ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock
Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Lock Owner: harry
Lock Created: 2006-06-08 07:29:18 -0500 (Thu, 08 June 2006)
Lock Comment (1 line):
Making some tweaks. Locking for the next two hours.
我们鼓励用户和管理员都应该给不能根据上下文的文件添加svn:needs-lock属性，这是鼓励好的锁定习惯和防止浪费的主要技术手段。
需要注意到这个属性是依赖于锁定系统的交流工具，不管是否有这个属性，文件都可以锁定。相反的，无论有没有这个属性，并不会要求提交需要首先锁定文件。
这个系统并不是毫无瑕疵，即使有这个属性，只读提醒也有可能失效。有些程序“偷偷的篡改了”文件的只读属性，悄无声息的允许用户编辑和保存文件，不幸的是，Subversion对此无能为力—即使到了现今，还是没有任何工具能够代替人与人的良好交流。
分支与合并
创建分支
建立分支非常的简单—使用svn copy命令给你的工程做个拷贝，Subversion不仅可以拷贝单个文件，也可以拷贝整个目录，在目前情况下，你希望作/calc/trunk的拷贝，新的拷贝应该在哪里？在你希望的任何地方—它只是在于项目的政策，我们假设你们项目的政策是在/calc/branches建立分支，并且你希望把你的分支叫做my-calc-branch，你希望建立一个新的目录/calc/branches/my-calc-branch，作为/calc/trunk的拷贝开始它的生命周期。
有两个方法作拷贝，我们先介绍一个混乱的方法，只是让概念更清楚，首先取出一个项目的根目录，/calc：
$ svn checkout http://svn.example.com/repos/calc bigwc
A bigwc/trunk/
A bigwc/trunk/Makefile
A bigwc/trunk/integer.c
A bigwc/trunk/button.c
A bigwc/branches/
Checked out revision 340.
建立一个备份只是传递两个目录参数到svn copy命令：
$ cd bigwc
$ svn copy trunk branches/my-calc-branch
$ svn status
A + branches/my-calc-branch
在这个情况下，svn copy命令迭代的将trunk工作目录拷贝到一个新的目录branhes/my-calc-branch，像你从svn status看到的，新的目录是准备添加到版本库的，但是也要注意A后面的“+”号，这表明这个准备添加的东西是一份备份，而不是新的东西。当你提交修改，Subversion会通过拷贝/calc/trunk建立/calc/branches/my-calc-branch目录，而不是通过网络传递所有数据：
$ svn commit -m "Creating a private branch of /calc/trunk."
Adding branches/my-calc-branch
Committed revision 341.
现在，我们必须告诉你建立分支最简单的方法：svn copy可以直接对两个URL操作。
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Creating a private branch of /calc/trunk."
Committed revision 341.
从版本库的视点来看，其实这两种方法没有什么区别，两个过程都在版本341建立了一个新目录作为/calc/trunk的一个备份，注意第二种方法，只是执行了一个立即提交。 这是一个简单的过程，因为你不需要取出版本库一个庞大的镜像，事实上，这个技术不需要你有工作拷贝，这是大多数用户创建分支的方式。
廉价复制
Subversion的版本库有特殊的设计，当你复制一个目录，你不需要担心版本库会变得十分巨大—Subversion并不是拷贝所有的数据，相反，它建立了一个已存在目录树的入口，如果你是Unix用户，可以把它理解成硬链接，在对拷贝的文件和目录操作之前，Subversion还仅仅把它当作硬链接，只有为了区分不同版本的对象时才会复制数据。
这就是为什么经常听到Subversion用户谈论“廉价的拷贝”，与目录的大小无关—这个操作会使用很少的时间，事实上，这个特性是Subversion提交工作的基础：每一次版本都是前一个版本的一个“廉价的拷贝”，只有少数项目修改了。（要阅读更多关于这部分的内容，访问Subversion网站并且阅读设计文档中的“bubble up”方法）。
当然，拷贝与分享的内部机制对用户来讲是不可见的，用户只是看到拷贝树，这里的要点是拷贝的时间与空间代价很小。如果你完全在版本库里创建分支（通过运行svn copy URL1 URL2），这是一个快速的，时间基本固定的操作，只要你希望，可以随意创建分支。
分支背后的关键概念
在本节，你需要记住两件重要的课程。首先，Subversion并没有内在的分支概念—只有拷贝，当你拷贝一个目录，这个结果目录就是一个“分支”，只是因为你给了它这样一个含义而已。你可以换一种角度考虑，或者特别对待，但是对于Subversion它只是一个普通的拷贝，只不过碰巧包含了一些额外的历史信息。第二，因为拷贝机制，Subversion的分支是以普通文件系统目录存在的，这与其他版本控制系统不同，它们都为分支定义了另一维度的“标签”。
保持分支与主干同步
Keeping a Branch in Sync
Subversion is aware of the history of your branch and knows when it divided away from thetrunk. To replicate the latest, greatest trunk changes to your branch, first make sure your working copy of the branch is “clean”—that it has no local modifications reported by svn status. Then simply run:
$ pwd
/home/user/my-calc-branch
$ svn merge http://svn.example.com/repos/calc/trunk
--- Merging r345 through r356 into '.':
U
button.c
U
integer.c
This basic syntax—svn merge URL—tells Subversion to merge all recent changes from the URL to the current working directory (which is typically the root of your working copy). After running the prior example, your branch working copy now contains new local modifications, and these edits are duplications of all of the changes that have happened on the trunk since you first created your branch:
$ svn status
M
.
M
button.c
M
integer.c
At this point, the wise thing to do is look at the changes carefully with svn diff, and then build and test your branch. Notice that the current working directory (“.”) has also been modified; the svn diff will show that its svn:mergeinfo property has been either created or modified. This is important merge-related metadata that you should not touch, since it will be needed by future svn merge commands.
After performing the merge, you might also need to resolve some conflicts (just as you do with svn update) or possibly make some small edits to get things working properly. (Remember, just because there are no syntactic conflicts doesn't mean there aren't any semantic conflicts!) If you encounter serious problems, you can always abort the local changes by running svn revert . -R (which will undo all local modifications) and start a long “what's going on?” discussion with your collaborators. If things look good, however, you can submit these changes into the repository:
$ svn commit -m "Merged latest trunk changes to my-calc-branch."
Sending
.
Sending
button.c
Sending
integer.c
Transmitting file data ..
Committed revision 357.
At this point, your private branch is now “in sync” with the trunk, so you can rest easier knowing that as you continue to work in isolation, you're not drifting too far away from what everyone else is doing.
合并分支到主干上
What happens when you finally finish your work, though? Your new feature is done, and you're ready to merge your branch changes back to the trunk (so your team can enjoy the bounty of your labor). The process is simple. First, bring your branch in sync with the trunk again, just as you've been doing all along:
$ svn merge http://svn.example.com/repos/calc/trunk
--- Merging r381 through r385 into '.':
U
button.c
U
README
$ # build, test, ...
$ svn commit -m "Final merge of trunk changes to my-calc-branch."
Sending
.
Sending
button.c
Sending
README
Transmitting file data ..
Committed revision 390.
Now, you use svn merge to replicate your branch changes back into the trunk. You'll need an up-to-date working copy of /trunk. You can do this by either doing an svn checkout, dredging up an old trunk working copy from somewhere on your disk, or using svn switch (see the section called “Traversing Branches”.) However you get a trunk working copy, remember that it's a best practice to do your merge into a working copy that has no local edits and has been recently updated (i.e., is not a mixture of local revisions). If your working copy isn't “clean” in these ways, you can run into some unnecessary conflict-related headaches and svn merge will likely return an error. Once you have a clean working copy of the trunk, you're ready to merge your branch back into it:
$ pwd
/home/user/calc-trunk
$ svn update # (make sure the working copy is up to date)
At revision 390.
$ svn merge --reintegrate http://svn.example.com/repos/calc/branches/my-calc-bra
--- Merging differences between repository URLs into '.':
U
button.c
U
integer.c
U
Makefile
U
.
$ # build, test, verify, ...
$ svn commit -m "Merge my-calc-branch back into trunk!"
Sending
.
Sending
button.c
Sending
integer.c
Sending
Makefile
Transmitting file data ..
Committed revision 391.
Congratulations, your branch has now been remerged back into the main line of development. Notice our use of the --reintegrate option this time around. The option is critical for reintegrating changes from a branch back into its original line of development—don't forget it! It's needed because this sort of “merge back” is a different sort of work than what you've been doing up until now. Previously, we had been asking svn merge to grab the “next set” of changes from one line of development (the trunk) and duplicate them to another (your branch). This is fairly straightforward, and each time Subversion knows how to pick up where it left off. In our prior examples, you can see that first it merges the ranges Branching and Merging 345:356 from trunk to branch; later on, it continues by merging the next contiguously available range, 356:380. When doing the final sync, it merges the range 380:385.
When merging your branch back to the trunk, however, the underlying mathematics is quite different. Your feature branch is now a mishmosh of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest
trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!) Now that your private branch is merged to trunk, you may wish to remove it from the repository:
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Remove my-calc-branch."
Committed revision 392.
But wait! Isn't the history of that branch valuable? What if somebody wants to audit the evolution of your feature someday and look at all of your branch changes? No need to worry. Remember that even though your branch is no longer visible in the /branches directory, its existence is still an immutable part of the repository's history. A simple svn log command on the /branches URL will show the entire history of your branch. Your branch can even be resurrected at some point, should you desire (see the section called “Resurrecting Deleted Items”).
In Subversion 1.5, once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. It's not able to correctly absorb new trunk changes, nor can it be properly reintegrated to trunk again. For this reason, if you want to keep working on your feature branch, we recommend destroying it and then re-creating it from the trunk:
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Remove my-calc-branch."
Committed revision 392.
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/new-branch
-m "Create a new branch from trunk."
Committed revision 393.
$ cd my-calc-branch
$ svn switch http://svn.example.com/repos/calc/branches/new-branch
Updated to revision 393.
The final command in the prior example—svn switch—is a way of updating an existing working copy to reflect a different repository directory. We'll discuss this more in the section called “Traversing Branches”.
While it's perfectly fine to experiment with merges by running svn merge and svn revert over and over, you may run into some annoying (but easily bypassed) roadblocks. For example, if the merge operation adds a new file (i.e., schedules it for addition), svn revert won't actually remove the file; it simply
unschedules the addition. You're left with an unversioned file. If you then attempt to run the merge again, you may get conflicts due to the unversioned file “being in the way.” Solution? After performing a revert, be sure to clean up the working copy and remove unversioned files and directories. The output of svn status should be as clean as possible, ideally showing no output.
取消改变
Undoing Changes
An extremely common use for svn merge is to roll back a change that has already been committed. Suppose you're working away happily on a working copy of /calc/trunk, and you discover that the change made way back in revision 303, which changed integer.c, is completely wrong. It never should have been committed. You can use svn merge to “undo” the change in your working copy, and then commit the local modification to the repository. All you need to do is to specify a reverse difference. (You can do this by specifying --revision 303:302, or by an equivalent --change -303.)
$ svn merge -c -303 http://svn.example.com/repos/calc/trunk
--- Reverse-merging r303 into 'integer.c':
U
integer.c
$ svn status
M
.
M
integer.c
$ svn diff
...
# verify that the change is removed
...
$ svn commit -m "Undoing change committed in r303."
Sending
integer.c
Transmitting file data .
Committed revision 350.
As we mentioned earlier, one way to think about a repository revision is as a specific changeset. By using the -r option, you can ask svn merge to apply a changeset, or a whole range of changesets, to your working copy. In our case of undoing a change, we're asking svn merge to apply changeset #303 to our working copy backward. Keep in mind that rolling back a change like this is just like any other svn merge operation, so you should use svn status and svn diff to confirm that your work is in the state you want it to be in, and then use svn commit to send the final version to the repository. After committing, this particular changeset is no longer reflected in the HEAD revision. Again, you may be thinking: well, that really didn't undo the commit, did it? The change still exists in revision 303. If somebody checks out a version of the calc project between revisions 303 and 349, she'll still see the bad change, right?
Yes, that's true. When we talk about “removing” a change, we're really talking about removing it from the HEAD revision. The original change still exists in the repository's history. For most situations, this is good enough. Most people are only interested in tracking the HEAD of a project anyway. There are special cases, however, where you really might want to destroy all evidence of the commit. (Perhaps somebody accidentally committed a confidential document.) This isn't so easy, it turns out, because Subversion was deliberately designed to never lose information. Revisions are immutable trees that build upon one another. Removing a revision from history would cause a domino effect, creating chaos in all subsequent revisions and possibly invalidating all working copies.
恢复已删内容
Resurrecting Deleted Items
The great thing about version control systems is that information is never lost. Even when you delete a file or directory, it may be gone from the HEAD revision, but the object still exists in earlier revisions. One of the most common questions new users ask is, “How do I get my old file or directory back?”
The first step is to define exactly which item you're trying to resurrect. Here's a useful metaphor: you can think of every object in the repository as existing in a sort of twodimensional coordinate system. The first coordinate is a particular revision tree, and the second coordinate is a path within that tree. So every version of your file or directory can be defined by a specific coordinate pair. (Remember the “peg revision” syntaxfoo.c@224—mentioned back in the section called “Peg and Operative Revisions”.)
First, you might need to use svn log to discover the exact coordinate pair you wish to resurrect. A good strategy is to run svn log --verbose in a directory that used to contain your deleted item. The --verbose (-v) option shows a list of all changed items in each revision; all you need to do is find the revision in which you deleted the file or directory. You can do this visually, or by using another tool to examine the log output (via grep, or
perhaps via an incremental search in an editor).
$ cd parent-dir
$ svn log -v
…
------------------------------------------------------------------------
r808 | joe | 2003-12-26 14:29:40 -0600 (Fri, 26 Dec 2003) | 3 lines
Changed paths:
D /calc/trunk/real.c
M /calc/trunk/integer.c
Added fast fourier transform functions to integer.c.
Removed real.c because code now in double.c.
…
In the example, we're assuming that you're looking for a deleted file real.c. By looking through the logs of a parent directory, you've spotted that this file was deleted in revision 808. Therefore, the last version of the file to exist was in the revision right before that. Conclusion: you want to resurrect the path /calc/trunk/real.c from revision 807. That was the hard part—the research. Now that you know what you want to restore, you have two different choices.
One option is to use svn merge to apply revision 808 “in reverse.” (We already discussed how to undo changes in the section called “Undoing Changes”.) This would have the effect of re-adding real.c as a local modification. The file would be scheduled for addition, and after a commit, the file would again exist in HEAD.
In this particular example, however, this is probably not the best strategy. Reverse-applying revision 808 would not only schedule real.c for addition, but the log message indicates that it would also undo certain changes to integer.c, which you don't want. Certainly, you could reverse-merge revision 808 and then svn revert the local modifications to integer.c, but this technique doesn't scale well. What if 90 files were changed in revision 808?
A second, more targeted strategy is not to use svn merge at all, but rather to use the svn copy command. Simply copy the exact revision and path “coordinate pair” from the repository to your working copy:
$ svn copy http://svn.example.com/repos/calc/trunk/real.c@807 ./real.c
$ svn status
A + real.c
$ svn commit -m "Resurrected real.c from revision 807, /calc/trunk/real.c."
Adding real.c
Transmitting file data .
Committed revision 1390.
The plus sign in the status output indicates that the item isn't merely scheduled for addition, but scheduled for addition “with history.” Subversion remembers where it was copied from. In the future, running svn log on this file will traverse back through the file's resurrection and through all the history it had prior to revision 807. In other words, this new real.c isn't really new; it's a direct descendant of the original, deleted file. This is usually considered a good and useful thing.
Although our example shows us resurrecting a file, note that these same techniques work just as well for resurrecting deleted directories. Also note that a resurrection doesn't have to happen in your working copy—it can happen entirely in the repository.
合并某一个特定分支的内容
Cherrypicking
Just as the term “changeset” is often used in version control systems, so is the term cherrypicking. This word refers to the act of choosing one specific changeset from a branch and replicating it to another. Cherrypicking may also refer to the act of duplicating a particular set of (not necessarily contiguous!) changesets from one branch to another. This is in contrast to more typical merging scenarios, where the “next” contiguous range of revisions
is duplicated automatically.
Why would people want to replicate just a single change? It comes up more often than you'd think. For example, let's go back in time and imagine that you haven't yet merged your private feature branch back to the trunk. At the water cooler, you get word that Sally made an interesting change to integer.c on the trunk. Looking over the history of commits to the trunk, you see that in revision 355 she fixed a critical bug that directly impacts the feature you're working on. You might not be ready to merge all the trunk changes to your branch just yet, but you certainly need that particular bug fix in order to continue your work.
$ svn diff -c 355 http://svn.example.com/repos/calc/trunk
Index: integer.c
===================================================================
--- integer.c (revision 354)
+++ integer.c (revision 355)
@@ -147,7 +147,7 @@
case 6: sprintf(info->operating_system, "HPFS (OS/2 or NT)"); break;
case 7: sprintf(info->operating_system, "Macintosh"); break;
case 8: sprintf(info->operating_system, "Z-System"); break;
- case 9: sprintf(info->operating_system, "CP/MM");
+ case 9: sprintf(info->operating_system, "CP/M"); break;
case 10: sprintf(info->operating_system, "TOPS-20"); break;
case 11: sprintf(info->operating_system, "NTFS (Windows NT)"); break;
case 12: sprintf(info->operating_system, "QDOS"); break;
Just as you used svn diff in the prior example to examine revision 355, you can pass the same option to svn merge:
$ svn merge -c 355 http://svn.example.com/repos/calc/trunk
U integer.c
$ svn status
M integer.c
You can now go through the usual testing procedures before committing this change to your branch. After the commit, Subversion marks r355 as having been merged to the branch so that future “magic” merges that synchronize your branch with the trunk know to skip over r355. (Merging the same change to the same branch almost always results in a conflict!)
$ cd my-calc-branch
$ svn propget svn:mergeinfo .
/trunk:341-349,355
# Notice that r355 isn't listed as "eligible" to merge, because
# it's already been merged.
$ svn mergeinfo http://svn.example.com/repos/calc/trunk --show-revs eligible
r350
r351
r352
r353
r354
r356
r357
r358
r359
r360
$ svn merge http://svn.example.com/repos/calc/trunk
--- Merging r350 through r354 into '.':
U .
U integer.c
U Makefile
--- Merging r356 through r360 into '.':
U .
U integer.c
U button.c
This use case of replicating (or backporting) bug fixes from one branch to another is perhaps the most popular reason for cherrypicking changes; it comes up all the time, for example, when a team is maintaining a “release branch” of software. (We discuss this pattern in the section called “Release Branches”.)
Did you notice how, in the last example, the merge invocation caused two distinct ranges of merges to be applied? The svn merge command applied two
independent patches to your working copy to skip over changeset 355, which your branch already contained. There's nothing inherently wrong with this, except
that it has the potential to make conflict resolution trickier. If the first range of changes creates conflicts, you must resolve them interactively for the merge process to continue and apply the second range of changes. If you postpone a conflict from the first wave of changes, the whole merge command will bail out with an error message.
遍历分支，使用 svn switch 命令，可达到不同版本的文件组合成一个工程
Traversing Branches
The svn switch command transforms an existing working copy to reflect a different branch. While this command isn't strictly necessary for working with branches, it provides a nice shortcut. In our earlier example, after creating your private branch, you checked out a fresh working copy of the new repository directory. Instead, you can simply ask Subversion to change your working copy of /calc/trunk to mirror the new branch location:
$ cd calc
$ svn info | grep URL
URL: http://svn.example.com/repos/calc/trunk
$ svn switch http://svn.example.com/repos/calc/branches/my-calc-branch
U integer.c
U button.c
U Makefile
Updated to revision 341.
$ svn info | grep URL
URL: http://svn.example.com/repos/calc/branches/my-calc-branch
“Switching” a working copy that has no local modifications to a different branch results in the working copy looking just as it would if you'd done a fresh checkout of the directory. It's usually more efficient to use this command, because often branches differ by only a small degree. The server sends only the minimal set of changes necessary to make your working copy reflect the branch directory.
The svn switch command also takes a --revision (-r) option, so you need not always move your working copy to the HEAD of the branch. Of course, most projects are more complicated than our calc example, and contain multiple subdirectories. Subversion users often follow a specific algorithm when using
branches:
1. Copy the project's entire “trunk” to a new branch directory.
2. Switch only part of the trunk working copy to mirror the branch.
In other words, if a user knows that the branch work needs to happen on only a specific subdirectory, she uses svn switch to move only that subdirectory to the branch. (Or sometimes users will switch just a single working file to the branch!) That way, the user can continue to receive normal “trunk” updates to most of her working copy, but the switched portions will remain immune (unless someone commits a change to her branch). This feature adds a whole new dimension to the concept of a “mixed working copy”—not only can working copies contain a mixture of working revisions, but they can also contain a mixture of repository locations as well.
If your working copy contains a number of switched subtrees from different repository locations, it continues to function as normal. When you update, you'll receive patches to each subtree as appropriate. When you commit, your local changes will still be applied as a single, atomic change to the repository.
Note that while it's okay for your working copy to reflect a mixture of repository locations, these locations must all be within the same repository. Subversion repositories aren't yet able to communicate with one another; that feature is planned for the future.
Have you ever found yourself making some complex edits (in your /trunk working copy) and suddenly realized, “Hey, these changes ought to be in their
own branch?” A great technique to do this can be summarized in two steps:
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/newbranch \
-m "Create branch 'newbranch'."
Committed revision 353.
$ svn switch http://svn.example.com/repos/calc/branches/newbranch
At revision 353.
标签
另一个常见的版本控制系统概念是标¾（tag），一个标签只是一个项目某一时间的“快照”，在Subversion里这个概念无处不在—每一次提交的修订版本都是一个精确的快照。
然而人们希望更人性化的标签名称，像release-1.0。他们也希望可以对一个子目录快照，毕竟，记住release-1.0是修订版本4822的某一小部分不是件很容易的事。
建立简单标签
svn copy再次登场，你希望建立一个/calc/trunk的一个快照，就像HEAD修订版本，建立这样一个拷贝：
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/tags/release-1.0 \
-m "Tagging the 1.0 release of the 'calc' project."
Committed revision 351.
这个例子假定/calc/tags目录已经存在（如果不是，可以使用svn mkdir创建。），拷贝完成之后，一个表示当时HEAD版本的/calc/trunk目录的镜像已经永久的拷贝到release-1.0目录。当然，你会希望更精确一点，以防其他人在你不注意的时候提交修改，所以，如果你知道/calc/trunk的版本350是你想要的快照，你可以使用svn copy加参数 -r 350。
但是等一下：标签的产生过程与建立分支是一样的？是的，实际上在Subversion中标签与分支没有区别，都是普通的目录，通过copy命令得到，与分支一样，一个目录之所以是标签只是人们决定这样使用它，只要没有人提交这个目录，它永远是一个快照，但如果人们开始提交，它就变成了分支。
如果你管理一个版本库，你有两种方式管理标签，第一种方法是禁止命令：作为项目的政策，我们要决定标签所在的位置，确定所有用户知道如何处理拷贝的目录（也就是确保他们不会提交他们），第二种方法看来很过分：使用访问控制脚本来阻止任何想对标签目录做的非拷贝的操作这种方法通常是不必要的，如果一个人不小心提交了到标签目录一个修改，你可以简单的取消，毕竟这是版本控制啊。
建立复杂标签
有时候你希望你的“快照”能够很复杂，而不只是一个单独修订版本的一个单独目录。
举个例子，假定你的项目比我们的的例子calc大的多：假设它保存了一组子目录和许多文件，在你工作时，你或许决定创建一个包括特定特性和Bug修正的工作拷贝，你可以通过选择性的回溯文件和目录到特定修订版本（使用svn update -r）来实现，或者转换文件和目录到特定分支（使用svn switch），这样做之后，你的工作拷贝成为版本库不同版本和分支的司令部，但是经过测试，你会知道这是你需要的一种精确数据组合。
是时候进行快照了，拷贝URL在这里不能工作，在这个例子里，你希望把本地拷贝的布局做镜像并且保存到版本库中，幸运的是，svn copy包括四种不同的使用方式（在第 9 章 Subversion 完全参考可以详细阅读），包括拷贝工作拷贝到版本库：
$ ls
my-working-copy/
$ svn copy my-working-copy http://svn.example.com/repos/calc/tags/mytag
Committed revision 352.
现在在版本库有一个新的目录/calc/tags/mytag，这是你的本地拷贝的一个快照—混合了修订版本，URL等等。
一些人也发现这一特性一些有趣的使用方式，有些时候本地拷贝有一组本地修改，你希望你的协作者看到这些，不使用svn diff并发送一个补定文件（不会捕捉到目录、符号链和属性的修改），而是使用svn copy来“上传”你的工作拷贝到一个版本库的私有区域，你的协作者可以选择完整的取出你的工作拷贝，或使用svn merge来接受你的精确修改。
虽然这是上传快速工作拷贝快照的一个好方法，但这不是初始创建分支的好方法。分支创建必须是它本身的事件，而这个方法创建的分支包含了额外修改，都包含在一个单独修订版本里。这让我们很难识别分支点的单个修订版本号码。
你是否发现你做出了复杂的修改（在/trunk的工作拷贝），并突然发现，“这些修改必须在它们自己的分支？”处理这个问题的技术可以总结为两步：
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/newbranch
Committed revision 353.
$ svn switch http://svn.example.com/repos/calc/branches/newbranch
At revision 353.
就像svn update命令，svn switch会保留工作拷贝的本地修改，此刻，你的工作拷贝反映到新建的分支上，而你的下一次svn commit会发送修改到服务器。
供方分支（第三方库的管理）
当开发软件时有这样一个情况，你版本控制的数据可能关联于或者是依赖于其他人的数据，通常来讲，你的项目的需要会要求你自己的项目对外部实体提供的数据保持尽可能最新的版本，同时不会牺牲稳定性，这种情况总是会出现—只要某个小组的信息对另一个小组的信息有直接的影响。
举个例子，软件开发者会工作在一个使用第三方库的应用，Subversion恰好是和Apache的Portable Runtime library（见“Apache可移植运行库”一节）有这样一个关系。Subversion源代码依赖于APR库来实现可移植需求。在Subversion的早期开发阶段，项目紧密地追踪APR的API修改，经常在库代码的“流血的边缘”粘住，现在APR和Subversion都已经成熟了，Subversion只尝试同步APR的经过良好测试的，稳定的API库。
现在，如果你的项目依赖于其他人的信息，有许多方法可以用来尝试同步你的信息，最痛苦的，你可以为项目所有的贡献者发布口头或书写的指导，告诉他们确信他们拥有你们的项目需要的特定版本的第三方信息。如果第三方信息是用Subversion版本库维护，你可以使用Subversion的外部定义来有效的“强制”特定的版本的信息在你的工作拷贝的的位置（见“外部定义”一节）。
但是有时候，你希望在你自己的版本控制系统维护一个针对第三方数据的自定义修改，回到软件开发的例子，程序员为了他们自己的目的会需要修改第三方库，这些修改会包括新的功能和bug修正，在成为第三方工具官方发布之前，只是内部维护。或者这些修改永远不会传给库的维护者，只是作为满足软件开发需要的单独的自定义修改存在。
现在你会面对一个有趣的情形，你的项目可以用某种脱节的样式保持它关于第三方数据自己的修改，如使用补丁文件或者是完全的可选版本的文件和目录。但是这很快会成为维护的头痛的事情，需要一种机制来应用你对第三方数据的自定义修改，并且迫使在第三方数据的后续版本重建这些修改。
这个问题的解决方案是使用供方分支，一个供方分支是一个目录树保存了第三方实体或供应方的信息，每一个供应方数据的版本吸收到你的项目叫做供方drop。
供方分支提供了两个关键的益处，第一，通过在我们的版本控制系统保存现在支持的供方drop，你项目的成员不需要指导他们是否有了正确版本的供方数据，他们只需要作为不同工作拷贝更新的一部份，简单的接受正确的版本就可以了。第二，因为数据存在于你自己的Subversion版本库，你可以在恰当的位置保存你的自定义修改—你不需要一个自动的（或者是更坏，手工的）方法来交换你的自定义行为。
常规的供方分支管理过程
管理供方分支通常会像这个样子，你创建一个顶级的目录（如/vendor）来保存供方分支，然后你导入第三方的代码到你的子目录。然后你将拷贝这个子目录到主要的开发分支（例如/trunk）的适当位置。你一直在你的主要开发分支上做本地修改，当你的追踪的代码有了新版本，你会把带到供方分支并且把它合并到你的/trunk，解决任何你的本地修改和他们的修改的冲突。
也许一个例子有助于我们阐述这个算法，我们会使用这样一个场景，我们的开发团队正在开发一个计算器程序，与一个第三方的复杂数字运算库libcomplex关联。我们从供方分支的初始创建开始，并且导入供方drop，我们会把每株分支目录叫做libcomplex，我们的代码drop会进入到供方分支的子目录current，并且因为svn import创建所有的需要的中间父目录，我们可以使用一个命令完成这一步。
$ svn import /path/to/libcomplex-1.0 \
http://svn.example.com/repos/vendor/libcomplex/current \
-m 'importing initial 1.0 vendor drop'
…
我们现在在/vendor/libcomplex/current有了libcomplex当前版本的代码，现在我们为那个版本作标签（见“标签”一节），然后拷贝它到主要开发分支，我们的拷贝会在calc项目目录创建一个新的目录libcomplex，它是这个我们将要进行自定义的供方数据的拷贝版本。
$ svn copy http://svn.example.com/repos/vendor/libcomplex/current \
http://svn.example.com/repos/vendor/libcomplex/1.0 \
-m 'tagging libcomplex-1.0'
…
$ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0 \
http://svn.example.com/repos/calc/libcomplex \
-m 'bringing libcomplex-1.0 into the main branch'
…
我们取出我们项目的主分支—现在包括了第一个供方释放的拷贝—我们开始自定义libcomplex的代码，在我们知道之前，我们的libcomplex修改版本是已经与我们的计算器程序完全集成了。 [23]
几周之后，libcomplex得开发者发布了一个新的版本—版本1.1—包括了我们很需要的一些特性和功能。我们很希望升级到这个版本，但不希望失去在当前版本所作的修改。我们本质上会希望把我们当前基线版本是的libcomplex1.0的拷贝替换为libcomplex 1.1，然后把前面自定义的修改应用到新的版本。但是实际上我们通过一个相反的方向解决这个问题，应用libcomplex从版本1.0到1.1的修改到我们修改的拷贝。
为了执行这个升级，我们取出一个我们供方分支的拷贝，替换current目录为新的libcomplex 1.1的代码，我们只是拷贝新文件到存在的文件上，或者是解压缩libcomplex 1.1的打包文件到我们存在的文件和目录。此时的目标是让我们的current目录只保留libcomplex 1.1的代码，并且保证所有的代码在版本控制之下，哦，我们希望在最小的版本控制历史扰动下完成这件事。
完成了这个从1.0到1.1的代码替换，svn status会显示文件的本地修改，或许也包括了一些未版本化或者丢失的文件，如果我们做了我们应该做的事情，未版本化的文件应该都是libcomplex在1.1新引入的文件—我们运行svn add来将它们加入到版本控制。丢失的文件是存在于1.1但是不是在1.1，在这些路径我们运行svn delete。最终一旦我们的current工作拷贝只是包括了libcomplex1.1的代码，我们可以提交这些改变目录和文件的修改。
我们的current分支现在保存了新的供方drop，我们为这个新的版本创建一个新的标签（就像我们为1.0版本drop所作的），然后合并这从个标签前一个版本的区别到主要开发分支。
$ cd working-copies/calc
$ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0 \
http://svn.example.com/repos/vendor/libcomplex/current \
libcomplex
… # resolve all the conflicts between their changes and our changes
$ svn commit -m 'merging libcomplex-1.1 into the main branch'
…
在这个琐碎的用例里，第三方工具的新版本会从一个文件和目录的角度来看，就像前一个版本。没有任何libcomplex源文件会被删除、被改名或是移动到别的位置—新的版本只会保存针对上一个版本的文本修改。在完美世界，我们对呢修改会干净得应用到库的新版本，不会产生任何并发和冲突。
但是事情总不是这样简单，实际上源文件在不同的版本间的移动是很常见的，这种过程复杂性可以确保我们的修改会一直对新的版本代码有效，可以很快使形势退化到我们需要在新版本手工的重新创建我们的自定义修改。一旦Subversion知道了给定文件的历史—包括了所有以前的位置—合并到新版本的进程就会很简单，但是我们需要负责告诉Subversion供方drop之间源文件布局的改变。
svn_load_dirs.pl
不仅仅包含一些删除、添加和移动的供方drops使得升级第三方数据后续版本的过程变得复杂，所以Subversion提供了一个svn_load_dirs.pl脚本来辅助这个过程，这个脚本自动进行我们前面提到的常规供方分支管理过程的导入步骤，从而使得错误最小化。你仍要负责使用合并命令合并第三方的新 版本数据合并到主要开发分支，但是svn_load_dirs.pl帮助你快速到达这一步骤。
一句话，svn_load_dirs.pl是一个增强的svn import，具备了许多重要的特性：
它可以在任何有一个存在的版本库目录与一个外部的目录匹配时执行，会执行所有必要的添加和删除并且可以选则执行移动。
它可以用来操作一系列复杂的操作，如那些需要一个中间媒介的提交—如在操作之前重命名一个文件或者目录两次。
它可以随意的为新导入目录打上标签。
它可以随意为符合正则表达式的文件和目录添加任意的属性。
svn_load_dirs.pl利用三个强制的参数，第一个参数是Subversion工作的基本目录URL，第二个参数在URL之后—相对于第一个参数—指向当前的供方分支将会导入的目录，最后，第三个参数是一个需要导入的本地目录，使用前面的例子，一个典型的svn_load_dirs.pl调用看起来如下：
$ svn_load_dirs.pl http://svn.example.com/repos/vendor/libcomplex \
current \
/path/to/libcomplex-1.1
…
你可以说明你会希望svn_load_dirs.pl同时打上标签，这使用-t命令行选项，需要指定一个标签名，这个标签是第一个参数的一个相对URL。
$ svn_load_dirs.pl -t libcomplex-1.1 \
http://svn.example.com/repos/vendor/libcomplex \
current \
/path/to/libcomplex-1.1
…
当你运行svn_load_dirs.pl，它会检验你的存在的“current”供方drop，并且与提议的新供方drop比较，在这个琐碎的例子里，没有文件只出现在一个版本里，脚本执行新的导入而不会发生意外。然而如果版本之间有了文件布局的区别，svn_load_dirs.pl会询问你如何解决这个区别，例如你会有机会告诉脚本libcomplex版本1.0的math.c文件在1.1已经重命名为arithmetic.c，任何没有解释为移动的差异都会被看作是常规的添加和删除。
这个脚本也接受单独配置文件用来为添加到版本库的文件和目录设置匹配正则表达式的属性。配置文件通过svn_load_dirs.pl的-p命令行选项指定，这个配置文件的每一行都是一个空白分割的两列或者四列值：一个Perl样式的正则表达式来匹配添加的路径、一个控制关键字（break或者是cont）和可选的属性名和值。
\.png$ break svn:mime-type p_w_picpath/png
\.jpe?g$ break svn:mime-type p_w_picpath/jpeg
\.m3u$ cont svn:mime-type audio/x-mpegurl
\.m3u$ break svn:eol-style LF
.* break svn:eol-style native
对每一个添加的路径，会按照顺序为匹配正则表达式的文件配置属性，除非控制标志是break（意味着不需要更多的路径匹配应用到这个路径）。如果控制说明是cont—continue的缩写—然后匹配工作会继续到配置文件的下一行。
任何正则表达式，属性名或者属性值的空格必须使用单引号或者双引号环绕，你可以使用反斜杠（\）换码符来回避引号，反斜杠只会在解析配置文件时回避引号，所以不能保护必要正则表达式字符之外的的其它字符。
而且完全没有bug，当然！