现在，我们将要深入到Subversion到使用细节当中，完成本章，你将学会所有日常使用的Subversion命令，你将从一个初始化检出开始，做出修改并检查，你也将会学到如何将别人的修改取到工作拷贝，检查他们，并解决所有可能发生的冲突。 这一章并不是Subversion命令的完全列表—而是你将会遇到的最常用任务的介绍，这一章假定你已经读过并且理解了，而且熟悉Subversion的模型，如果想查看所有命令的参考，见。 在继续阅读之前，需要知道Subversion使用中最重要的命令：svn help，Subversion命令行工具是一个自文档的工具—在任何时候你可以运行svn help <subcommand>来查看子命令的语法、参数以及行为方式。 使用svn import来导入一个新项目到Subversion的版本库，这恐怕是使用Subversion必定要做的第一步操作，但不是经常发生的事情，详细介绍可以看本章后面的。 在继续之前你一定要知道如何识别版本库的一个修订版本，像你在看到的，一个修订版本就是版本库的一个快照，当你的版本库持续扩大，你必须有手段来识别这些快照。 你可以使用--revision（-r）参数来选择特定修订版本（svn --revision REV），你也可以指定在两个修订版本之间的一个范围 （svn --revision REV1:REV2）。你可以在Subversion中通过修订版本号、关键字或日期指定特定修订版本。 当你新建了一个Subversion版本库，从修订版本号0开始，每一次成功的提交加1，当你提交成功，Subversion告诉客户端这个新版本号： $ svn commit --message "Corrected number of cheese slices." Sending sandwich.txt Transmitting file data . Committed revision 3. 如果你想在未来使用这个版本（我们将在此章的后面讲述我们这样做的方式和原因），你可以通过号码3指定。 Subversion客户端可以理解一些修订版本关键字，这些关键字可以用来代替--revision的数字参数，这会被Subversion解释到特定版本： 工作拷贝中的每一个目录都有一个叫作.svn的管理目录，工作目录中的每一个文件，Subversion在管理区域为它保留了一个备份，这是上一个版本（叫做BASE版本）没有修改的（没有关键字变化，没有行结束符号转化，没有任何改动）拷贝，我们把这个文件当作原始拷贝或基准文件使用，它与版本库中的文件完全一样。 HEAD 版本库中最新的（或者是最年轻的）版本。 BASE 工作拷贝中一个条目的修订版本号，如果这个版本在本地修改了，则BASE版本就是这个条目在本地未修改的版本。 COMMITTED 在BASE版本之前（或在Base）一个项目最后修改的版本。 PREV 一个项目最后修改版本之前的那个版本（技术上为COMMITTED -1）。 PREV、BASE、和COMMITTED指的都是本地路径而不是URL。 下面是一些关键字使用的例子，不要担心现在没有意义，我们将在本章的后面解释这些命令： $ svn diff --revision PREV:COMMITTED foo.c # shows the last change committed to foo.c $ svn log --revision HEAD # shows log message for the latest repository commit $ svn diff --revision HEAD # compares your working file (with local changes) to the latest version # in the repository $ svn diff --revision BASE:HEAD foo.c # compares your pristine foo.c (no local changes) with the # latest version in the repository $ svn log --revision BASE:HEAD # shows all commit logs since you last updated $ svn update --revision PREV foo.c # rewinds the last change on foo.c # (foo.c's working revision is decreased) 这些关键字允许你执行许多常用（而且有用）的操作，而不必去查询特定的修订版本号，或者记住本地拷贝的修订版本号。 在任何你使用特定版本号和版本关键字的地方，你也可以在{}中使用日期，你也可通过日期或者版本号配合使用来访问一段时间的修改！ 如下是一些Subversion能够接受的日期格式，注意在日期中有空格时需要使用引号。 $ svn checkout --revision {2002-02-17} $ svn checkout --revision {15:30} $ svn checkout --revision {15:30:00.200000} $ svn checkout --revision {"2002-02-17 15:30"} $ svn checkout --revision {"2002-02-17 15:30 +0230"} $ svn checkout --revision {2002-02-17T15:30} $ svn checkout --revision {2002-02-17T15:30Z} $ svn checkout --revision {2002-02-17T15:30-04:00} $ svn checkout --revision {20020217T1530} $ svn checkout --revision {20020217T1530Z} $ svn checkout --revision {20020217T1530-0500} … 当你指定一个日期，Subversion会在版本库找到接近这个日期的最新版本： $ svn log --revision {2002-11-28} ------------------------------------------------------------------------ r12 | ira | 2002-11-27 12:31:51 -0600 (Wed, 27 Nov 2002) | 6 lines … 如果你只是指定了日期而没有时间（举个例子2002-11-27），你也许会以为Subversion会给你11-27号最后的版本，相反，你会得到一个26号版本，甚至更早。记住Subversion会根据你的日期找到最新的版本，如果你给一个日期，而没有给时间，像2002-11-27，Subversion会假定时间是00:00:00，所以在27号找不到任何版本。 如果你希望查询包括27号，你既可以使用（{"2002-11-27 23:59"}），或是直接使用（{2002-11-28}）。 你可以使用时间段，Subversion会找到这段时间的所有版本： $ svn log --revision {2002-11-20}:{2002-11-29} … 我们也曾经指出，你可以混合日期和修订版本号： $ svn log --revision {2002-11-20}:4040 用户一定要认识到这种精巧会成为处理日期的绊脚石，因为一个版本的时间戳是作为一个属性存储的—不是版本化的，而是可以编辑的属性—版本号的时间戳可以被修改，从而建立一个虚假的年代表，也可以被完全删除。这将大大破坏Subversion的这种时间—版本转化功能的表现。 大多数时候，你会使用checkout从版本库取出一个新拷贝开始使用Subversion，这样会在本机创建一个项目的本地拷贝，这个拷贝包括版本库中的HEAD（最新的）版本： $ svn checkout http://svn.collab.net/repos/svn/trunk A trunk/subversion.dsw A trunk/svn_check.dsp A trunk/COMMITTERS A trunk/configure.in A trunk/IDEAS … Checked out revision 2499. Subversion努力控制版本控制下数据的类型，文件的内容和属性值都是按照二进制数据存储和传递，并且给Subversion提示以说明对于特定文件文本化的操作是没有意义的，也有一些地方，Subversion对存放信息的有限制。 Subversion内部使用二进制处理数据—例如，属性名称，路径名和日志信息—UTF-8编码的Unicode，这并不意味着与Subversion的交互必须完全使用UTF-8。作为一个惯例，Subversion的客户端能够透明的转化UTF-8和你所使用系统的编码，前提是可以进行有意义的转换（当然是大多数目前常见的编码）。 此外，路径名称在WebDAV交换中会作为XML属性值，就像Subversion的管理文件。这意味着路径名称只能包含合法的XML（1.0）字符，Subversion也会禁止路径名称中出现TAB、CR或LF字符，所以它们才不会在区别程序或如和的输出命令中断掉。 虽然看起来要记住很多事情，但在实践中这些限制很少会成为问题。只要你的本地设置兼容UTF-8，也不在路径名称中使用控制字符，与Subversion的通讯就不会有问题。命令行客户端会添加一些额外的帮助字节—自动将你输入的URL路径字符转化为合法正确的内部用版本。 有经验的Subversion用户也发展出了一套关于布局版本库路径的最佳实践习惯。这些不像上面提到的有严格的语法要求，它们是用来组织经常执行的任务。URL中的/trunk部分就是这种习惯，我们会在进一步论述这个问题并提出相关建议。 尽管上面的例子取出了trunk目录，你也完全可以通过输入特定URL取出任意深度的子目录： $ svn checkout http://svn.collab.net/repos/svn/trunk/doc/book/tools A tools/readme-dblite.html A tools/fo-stylesheet.xsl A tools/svnbook.el A tools/dtd A tools/dtd/dblite.dtd … Checked out revision 2499. 因为Subversion使用拷贝-修改-合并模型而不是锁定-修改-解锁模型（见），你可以开始修改工作拷贝中的目录和文件，你的工作拷贝和你的系统中的其它文件和目录完全一样，你可以编辑并改变它，移动它，也可以完全的删掉它，把它忘了。 因为你的工作拷贝同你的系统上的文件和目录没有什么区别，如果你希望重新规划工作拷贝，你必须要让Subversion知道，当你希望拷贝或者移动工作拷贝的一个项目时，你应该使用svn copy或者 svn move而不要使用操作系统的命令，我们会在以后的章节详细介绍。 除非你准备好了提交一个新文件或目录，或改变了已存在的，否则没有必要通知Subversion你做了什么。 工作拷贝中的任何一个目录包括一个名为.svn管理区域，通常列表操作不显示这个目录，但它仍然是一个非常重要的目录，无论你做什么？不要删除或是更改这个管理区域的任何东西，Subversion使用它来管理工作拷贝。 因为你可以使用版本库的URL作为唯一参数取出一个工作拷贝，你也可以在版本库URL之后指定一个目录，这样会将你的工作目录放到你的新目录，举个例子： $ svn checkout http://svn.collab.net/repos/svn/trunk subv A subv/subversion.dsw A subv/svn_check.dsp A subv/COMMITTERS A subv/configure.in A subv/IDEAS … Checked out revision 2499. 这样将把你的工作拷贝放到subv而不是和前面那样放到trunk。 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让你的工作拷贝与最新的版本同步。 $ svn update U foo.c U bar.c Updated to revision 2. 这种情况下，其他人在你上次更新之后提交了对foo.c和bar.c的修改，因此Subversion更新你的工作拷贝来引入这些更改。 让我们认真检查svn update的输出，当服务器发送修改到你的工作拷贝，一个字母显示在每一个项目之前，来让你知道Subversion对你的工作拷贝做了什么操作： U foo 文件foo更新了（从服务器收到修改）。 A foo 文件或目录foo被添加到工作拷贝。 D foo 文件或目录foo在工作拷贝被删除了。 R foo 文件或目录foo在工作拷贝已经被替换了，这是说，foo被删除，而一个新的同样名字的项目添加进来，它们具有同样的名字，但是版本库会把它们看作具备不同历史的不同对象。 G foo 文件foo接收到版本库的更改，你的本地版本也已经修改，但改变没有互相影响，Subversion成功的将版本库和本地文件合并，没有发生任何问题。 C foo 文件foo的修改与服务器冲突，服务器的修改与你的修改交迭在一起，不要恐慌，这种冲突需要人（你）来解决，我们在后面的章节讨论这种情况。 现在你可以开始工作并且修改你的工作拷贝了，你很容易决定作出一个修改（或者是一组），像写一个新的特性，修正一个错误等等。这时可以使用的Subversion命令包括svn add、 svn delete、svn copy和svn move。如果你只是修改版本库中已经存在的文件，在你提交之前，不必使用上面的任何一个命令。你可以对工作备份作的修改包括： 文件修改 这是最简单的一种修改，你不必告诉Subversion你想修改哪一个文件，只需要去修改，然后Subversion会自动地探测到哪些文件已经更改了。 目录树修改 你可以标记目录或者文件为预定要删除、增加、复制或者移动，也许这些改动在你的工作拷贝马上发生，而版本库只在你提交的时候才发生改变。 修改文件，可以使用文本编辑器、字处理软件、图形程序或任何你常用的工具，Subverion处理二进制文件像同文本文件一样—效率也一样。 这些是常用的可以修改目录树结构的子命令（我们会在后面包括svn import和svn mkdir）。 你可以使用任何你喜欢的工具编辑文件，但你不可以在修改目录结构时不通知Subversion，需要使用svn copy、svn delete和svn move命令修改工作拷贝的结构，使用svn add增加版本控制的新文件或目录。 svn add foo 预定将文件、目录或者符号链foo添加到版本库，当你下次提交后，foo会成为其父目录的一个子对象。注意，如果foo是目录，所有foo中的内容也会预定添加进去，如果你只想添加foo本身，使用--non-recursive（-N）参数。 svn delete foo 预定将文件、目录或者符号链foo从版本库中删除掉，如果foo是文件，它马上从工作拷贝中删除，如果是目录，不会被删除，但是Subversion准备好删除了，当你提交你的修改，foo就会在你的工作拷贝和版本库中被删除。当然没有任何东西是在版本库里被删除了—只是在版本库的HEAD里消失了，你可以通过检出（或者更新你的工作拷贝）你做出删除操作的前一个修订版本来找回所有的东西。 svn copy foo bar 建立一个新的项目bar作为foo的复制品，当在下次提交时会将bar添加到版本库，这种拷贝历史会记录下来（按照来自foo的方式记录），svn copy并不建立中介目录。 svn move foo bar 这个命令与与运行svn copy foo bar; svn delete foo完全相同，bar作为foo的拷贝准备添加，foo已经预定要被删除，svn move不建立中介的目录。 本章的前面曾经说过，为了使版本库反映你的改动，你应该提交所有改动。这并不完全正确—有一些方式是可以直接操作版本库的，当然只有子命令直接操作URL而不是本地拷贝路径时才可以实现，通常svn mkdir、svn copy、svn move、和 svn delete可以使用URL工作。 指定URL的操作方式有一些区别，因为在使用工作拷贝的运作方式时，工作拷贝成为一个集结地，可以在提交之前整理组织所要做的修改，直接对URL操作就没有这种奢侈，所以当你直接操作URL的时候，所有以上的动作代表一个立即的提交。 当你完成修改，你需要提交他们到版本库，但是在此之前，检查一下做过什么修改是个好主意，通过提交前的检查，你可以整理一份精确的日志信息，你也可以发现你不小心修改的文件，给了你一次恢复修改的机会。此外，这是一个审查和仔细察看修改的好机会，你可通过命令svn status、svn diff和svn revert精确地察看所做的修改。你可以使用前两个命令察看工作拷贝中的修改，使用第三个来撤销部分（或全部)的修改。 Subversion已经被优化来帮助你完成这个任务，可以在不与版本库通讯的情况下做许多事情，详细来说，对于每一个文件，你的的工作拷贝在.svn包含了一个原始的拷贝，所以Subversion可以快速的告诉你那些文件修改了，甚至允许你在不与版本库通讯的情况下恢复修改。 相对于其他命令，你会更多地使用这个svn status命令。 你也许使用cvs update来看你做了哪些修改，svn status会给你所有你做的改变—而不需要访问版本库，并且不会在不知情的情况下与其他用户作的更改比较。 在Subversion，update只是做这件事—将工作拷贝更新到版本库的最新版本，你可以消除使用update察看本地修改的习惯。 如果你在工作拷贝的顶级目录运行不带参数的svn status命令，它会检测你做的所有的文件或目录的修改，以下的例子是来展示svn status可能返回的状态码（注意，#之后的不是svn status打印的）。 L some_dir # svn已经在.svn目录锁定了some_dir M bar.c # bar.c的内容已经在本地修改过了 M baz.c # baz.c属性有修改，但没有内容修改 X 3rd_party # 这个目录是外部定义的一部分 ? foo.o # svn并没有管理foo.o ! some_dir # svn管理这个，但它可能丢失或者不完 ~ qux # 作为file/dir/link进行了版本控制，但类型已经改变 I .screenrc # svn不管理这个，配置确定要忽略它 A + moved_dir # 包含历史的添加，历史记录了它的来历 M + moved_dir/README # 包含历史的添加，并有了本地修改 D stuff/fish.c # 这个文件预定要删除 A stuff/loot/bloo.h # 这个文件预定要添加 C stuff/loot/lump.c # 这个文件在更新时发生冲突 C stuff/loot/glub.c # 文件在更新时发生属性冲突 R xyz.c # 这个文件预定要被替换 S stuff/squawk # 这个文件已经跳转到了分支 K dog.jpg # 文件在本地锁定；有锁定令牌 O cat.jpg # 文件在版本库被其他用户锁定 B bird.jpg # 文件本地锁定，但锁定发生错误 T fish.jpg # 文件本地锁定，但锁定丢失 在这种格式下，svn status打印五列字符，紧跟一些空格，接着是文件或者目录名。第一列告诉一个文件的状态或它的内容，返回代码解释如下： A item 文件、目录或是符号链item预定加入到版本库。 C item 文件item发生冲突，在从服务器更新时与本地版本发生交迭，在你提交到版本库前，必须手工的解决冲突。 D item 文件、目录或是符号链item预定从版本库中删除。 M item 文件item的内容被修改了。 R item 文件、目录或是符号链item预定将要替换版本库中的item，这意味着这个对象首先要被删除，另外一个同名的对象将要被添加，所有的操作发生在一个修订版本。 X item 目录没有版本化，但是与Subversion的外部定义关联，关于外部定义，可以看。 ? item 文件、目录或是符号链item不在版本控制之下，你可以通过使用svn status的--quiet（-q）参数或父目录的svn:ignore属性忽略这个问题，关于忽略文件的使用，见。 ! item 文件、目录或是符号链item在版本控制之下，但是已经丢失或者不完整，这可能因为使用非Subversion命令删除造成的，如果是一个目录，有可能是检出或是更新时的中断造成的，使用svn update可以重新从版本库获得文件或者目录，也可以使用svn revert file恢复原来的文件。 ~ item 文件、目录或是符号链item在版本库已经存在，但你的工作拷贝中的是另一个。举一个例子，你删除了一个版本库的文件，新建了一个在原来的位置，而且整个过程中没有使用svn delete或是svn add。 I item 文件、目录或是符号链item不在版本控制下，Subversion已经配置好了会在svn add、svn import和svn status命令忽略这个文件，关于忽略文件，见。注意，这个符号只会在使用svn status的参数--no-ignore时才会出现—否则这个文件会被忽略且不会显示！ 第二列说明文件或目录的属性的状态（更多细节可以看），如果一个M出现在第二列，说明属性被修改了，否则显示空白。 第三列只显示空白或者L，L表示Subversion已经锁定了这个目录的工作区域.svn，当你的svn commit正在运行的时候—也许正在输入log信息，运行svn status你可以看到L标记，如果这时候Subversion并没有运行，可以推测Subversion发生中断并且已经锁定，你必须运行svn cleanup来清除锁定（本节后面将有更多论述）。 第四列只会显示空白或+，+的意思是一个有附加历史信息的文件或目录预定添加或者修改到版本库，通常出现在svn move或是svn copy时，如果是看到A  +就是说要包含历史的增加，它可以是一个文件或是拷贝的根目录。+表示它是即将包含历史增加到版本库的目录的一部分，也就是说他的父目录要拷贝，它只是跟着一起的。 M  +表示将要包含历史的增加，并且已经更改了。当你提交时，首先会随父目录进行包含历史的增加，然后本地的修改提交到更改后的版本。 第五列只显示空白或是S，表示这个目录或文件已经转到了一个分支下了（使用svn switch）。 第六列显示了锁定的信息，将会在详细说明。（这与第三列中的L并不是同一个东西，见。） 如果你传递一个路径给svn status，它只给你这个项目的信息： $ svn status stuff/fish.c D stuff/fish.c svn status也有一个--verbose（-v）选项，它可以显示工作拷贝中的所有项目，即使没有改变过： $ svn status --verbose 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 --show-updates --verbose 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精确的找出你所做的修改，这会输出统一区别格式：Subversion使用内置区别引擎，缺省情况下输出为统一区别格式。如果你期望不同的输出格式，你可以使用--diff-cmd指定外置的区别程序，并且通过--extensions传递其他参数，举个例子，察看本地文件foo.c的区别，同时忽略空格修改，你可以运行svn diff --diff-cmd /usr/bin/diff --extensions '-bc' foo.c。 $ svn diff Index: bar.c =================================================================== --- bar.c (revision 3) +++ bar.c (working copy) @@ -1,7 +1,12 @@ +#include <sys/types.h> +#include <sys/stat.h> +#include <unistd.h> + +#include <stdio.h> int main(void) { - printf("Sixty-four slices of American Cheese...\n"); + printf("Sixty-five slices of American Cheese...\n"); 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 举个例子，你可以把补丁文件发送邮件到其他开发者，在提交之前审核和测试。 假设你通过上面的diff输出发现你不小心用编辑器在README中输入了一些字符。 这是使用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 revert ITEM的效果与删除ITEM然后执行svn update -r BASE ITEM完全一样，但是，如果你使用svn revert它不必通知版本库就可以恢复文件。 或许你不小心删除了一个文件： $ svn status README README $ svn delete README D README $ svn revert README Reverted 'README' $ svn status README README 这三个命令（svn status、svn diff和 svn revert）都可以在没有网络的情况下工作，这让你在没有网络连接时的管理修改过程更加简单，像在飞机上旅行，乘坐火车往返或是在海滩上奋力工作时。 Subversion通过在.svn管理区域使用原始的版本缓存来做到这一点，这使得恢复本地版本而不必访问网络，这个缓存（叫做text-base）也允许Subversion可以根据原始版本生成一个压缩的增量（区别） 提交—即使你有个非常快的网络，有这样一个缓存有极大的好处，非常的快，只向服务器提交修改的部分，这一点乍一看好像并不重要，但当你要提交一个400M大小的文件的修改时，你就会明白！ 我们可以使用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 --message "Add a few more things" svn: Commit failed (details follow): svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict 如果你遇到冲突，三件事你可以选择： 手动合并冲突文本（检查和修改文件中的冲突标志）。 用某一个临时文件覆盖你的工作文件。 运行svn revert <filename>来放弃所有的修改。 一旦你解决了冲突，你需要通过命令svn resolved让Subversion知道，这样就会删除三个临时文件，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，你没办法从从意大利熟食店得到想要的泡菜。如果你向他们询问，他们非常有理由把你带到城外的铁轨上。一旦你们确认了提交内容后，修改文件并且删除冲突标志。 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." 记住，如果你修改冲突时感到混乱，你可以参考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 sandwich.txt Reverted 'sandwich.txt' $ ls sandwich.* sandwich.txt 注意，当你恢复一个冲突的文件时，不需要再运行svn resolved。 现在我们准备好提交修改了，注意svn resolved不像我们本章学过的其他命令一样需要参数，在任何你认为解决了冲突的时候，只需要小心运行svn resolved，—一旦删除了临时文件，Subversion会让你提交这文件，即使文件中还存在冲突标记。 最后！你的修改结束了，你合并了服务器上所有的修改，你准备好提交修改到版本库。 svn commit命令发送所有的修改到版本库，当你提交修改时，你需要提供一些描述修改的日志信息，你的信息会附到这个修订版本上，如果信息很简短，你可以在命令行中使用--message（-m）选项： $ svn commit --message "Corrected number of cheese slices." Sending sandwich.txt Transmitting file data . Committed revision 3. 然而，如果你把写日志信息当作工作的一部分，你也许会希望通过告诉Subversion一个文件名得到日志信息，使用--file选项： $ svn commit --file 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 --message "Add another rule" Sending rules.txt svn: Commit failed (details follow): svn: Out of date: 'rules.txt' in transaction 'g' 此刻，你需要运行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 --revision 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结合使用，仅会显示修改的文件名。 当使用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 --revision 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 --revision 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 $ 你不仅可以用svn diff比较你工作拷贝中的文件，你甚至可以通过提供一个URL参数来比较版本库中两个文件的的区别，通常在本地机器没有工作拷贝时非常有用： $ svn diff --revision 4:5 http://svn.red-bean.com/repos/example/trunk/text/rules.txt … $ 如果你只是希望检查一个过去的版本而不希望察看它们的区别，使用svn cat： $ svn cat --revision 2 rules.txt Be kind to others Freedom = Chocolate Ice Cream Everything in moderation Chew with your mouth open $ 你可以重定向输出到一个文件： $ svn cat --revision 2 rules.txt > rules.txt.v2 $ 你一定疑惑为什么不只是使用svn update --revision ，将文件更新到旧的文件，我们有使用svn cat的原因。 首先，你或许希望使用外置的比较工具（或许是一个图形化的工具，或者你的格式无法用标准区别格式察看）察看这两个版本的区别，这种情况下，你需要得到一个旧的版本的拷贝，所以重定向到一个文件，并且在你的比较工具中指定这两个版本来察看区别。 有时候察看整个文件比只看区别要容易。 svn list可以在不下载文件到本地目录的情况下来察看目录中的文件： $ svn list http://svn.collab.net/repos/svn README branches/ clients/ tags/ trunk/ 如果你希望察看详细信息，你可以使用--verbose （-v）参数： $ svn list --verbose http://svn.collab.net/repos/svn 2755 harry 1331 Jul 28 02:07 README 2773 sally Jul 29 15:07 branches/ 2769 sally Jul 29 12:07 clients/ 2698 harry Jul 24 18:07 tags/ 2785 sally Jul 29 19:07 trunk/ 这些列告诉你文件和目录最后修改的修订版本、做出修改的用户、如果是文件还会有文件的大小，最后是修改日期和项目的名字。 除了以上的命令，你可以使用带参数--revision的svn update和svn checkout来使整个工作拷贝回到过去看到了吧？我们说过Subversion是一个时间机器。： $ svn checkout --revision 1729 # Checks out a new working copy at r1729 … $ svn update --revision 1729 # Updates an existing working copy to 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 svn import命令是拷贝用户的一个未被版本化的目录树到版本库最快的方法，如果需要，它也要建立一些中介文件。 $ svnadmin create /usr/local/svn/newrepos $ svn import mytree file:///usr/local/svn/newrepos/some/project \ -m "Initial import" Adding mytree/foo.c Adding mytree/bar.c Adding mytree/subdir Adding mytree/subdir/quux.h Committed revision 1. 在上一个例子里，将会拷贝目录mytree到版本库的some/project下： $ svn list file:///usr/local/svn/newrepos/some/project bar.c foo.c subdir/ 注意，在导入之后，原来的目录树并没有转化成工作拷贝，为了开始工作，你还是需要运行svn checkout导出一个工作拷贝。 不要将工作拷贝中的锁与并行版本控制的锁定-修改-解锁模型中用户使用的锁混淆；为了清楚的认识可以看一下。 我们已经覆盖了大多数Subversion的客户端命令，引人注目的例外是处理分支与合并（见）以及属性（见）的命令，然而你也许会希望跳到来察看所有不同的命令—怎样利用它们使你的工作更容易。