4. 基本的工作循环

4. 基本的工作循环
上一页	第 2 章基本使用	下一页

Subversion 有许多特性, 选项和华而不实的高级功能，但日常的工作中你只使用其中的一小部分，在这一节里，我们会介绍许多你在日常工作中常用的命令。

典型的工作周期是这样的：

Update your working copy. This involves the use of the svn update command.
Make your changes. The most common changes that you'll make are edits to the contents of your existing files. But sometimes you need to add, remove, copy and move files and directories—the svn add, svn delete, svn copy, and svn move commands handle those sorts of structural changes within the working copy.
Review your changes. The svn status and svn diff commands are critical to reviewing the changes you've made in your working copy.
Fix your mistakes. Nobody's perfect, so as you review your changes, you may spot something that's not quite right. Sometimes the easiest way to fix a mistake is start all over again from scratch. The svn revert command restores a file or directory to its unmodified state.
Resolve any conflicts (merge others' changes). In the time it takes you to make and review your changes, others might have made and published changes, too. You'll want to integrate their changes into your working copy to avoid the potential out-of-dateness scenarios when you attempt to publish your own. Again, the svn update command is the way to do this. If this results in local conflicts, you'll need to resolve those using the svn resolve command.
Publish (commit) your changes. The svn commit command transmits your changes to the repository where, if they are accepted, they create the newest versions of all the things you modified. Now others can see your work, too!

4.1. 更新你的工作副本

When working on a project that is being modified via multiple working copies, you'll want to update your working copy to receive any changes committed from other working copies since your last update. These might be changes that other members of your project team have made, or they might simply be changes you've made yourself from a different computer. To protect your data, Subversion won't allow you commit new changes to out-of-date files and directories, so it's best to have the latest versions of all your project's files and directories before making new changes of your own.

Use svn update to bring your working copy into sync with the latest revision in the repository:

$ svn update
U    foo.c
U    bar.c
Updated to revision 2.
$

这种情况下，其他人在你上次更新之后提交了对foo.c和bar.c的修改，因此Subversion更新你的工作副本来引入这些更改。

When the server sends changes to your working copy via svn update, a letter code is displayed next to each item to let you know what actions Subversion performed to bring your working copy up to date. To find out what these letters mean, run svn help update or see svn update (up).

4.2. 开始修改

Now you can get to work and make changes in your working copy. You can make two kinds of changes to your working copy: file changes and tree changes. You don't need to tell Subversion that you intend to change a file; just make your changes using your text editor, word processor, graphics program, or whatever tool you would normally use. Subversion automatically detects which files have been changed, and in addition, it handles binary files just as easily as it handles text files—and just as efficiently, too. Tree changes are different, and involve changes to a directory's structure. Such changes include adding and removing files, renaming files or directories, and copying files or directories to new locations. For tree changes, you use Subversion operations to “schedule” files and directories for removal, addition, copying, or moving. These changes may take place immediately in your working copy, but no additions or removals will happen in the repository until you commit them.

版本控制符号连接

On non-Windows platforms, Subversion is able to version files of the special type symbolic link (or “symlink”). A symlink is a file that acts as a sort of transparent reference to some other object in the filesystem, allowing programs to read and write to those objects indirectly by performing operations on the symlink itself.

When a symlink is committed into a Subversion repository, Subversion remembers that the file was in fact a symlink, as well as the object to which the symlink “points.” When that symlink is checked out to another working copy on a non-Windows system, Subversion reconstructs a real filesystem-level symbolic link from the versioned symlink. But that doesn't in any way limit the usability of working copies on systems such as Windows that do not support symlinks. On such systems, Subversion simply creates a regular text file whose contents are the path to which the original symlink pointed. While that file can't be used as a symlink on a Windows system, it also won't prevent Windows users from performing their other Subversion-related activities.

下面是 Subversion 用来修改目录树结构的五个最常用的子命令。

svn add FOO: Use this to schedule the file, directory, or symbolic link FOO to be added to the repository. When you next commit, FOO will become a child of its parent directory. Note that if FOO is a directory, everything underneath FOO will be scheduled for addition. If you want only to add FOO itself, pass the --depth=empty option.
svn delete FOO: Use this to schedule the file, directory, or symbolic link FOO to be deleted from the repository. If FOO is a file or link, it is immediately deleted from your working copy. If FOO is a directory, it is not deleted, but Subversion schedules it for deletion. When you commit your changes, FOO will be entirely removed from your working copy and the repository.^[6]
svn copy FOO BAR: Create a new item BAR as a duplicate of FOO and automatically schedule BAR for addition. When BAR is added to the repository on the next commit, its copy history is recorded (as having originally come from FOO). svn copy does not create intermediate directories unless you pass the --parents option.
svn move FOO BAR: This command is exactly the same as running svn copy FOO BAR; svn delete FOO. That is, BAR is scheduled for addition as a copy of FOO, and FOO is scheduled for removal. svn move does not create intermediate directories unless you pass the --parents option.
svn mkdir FOO: This command is exactly the same as running mkdir FOO; svn add FOO. That is, a new directory named FOO is created and scheduled for addition.

不通过工作副本修改版本库

Subversion does offer ways to immediately commit tree changes to the repository without an explicit commit action. In particular, specific uses of svn mkdir, svn copy, svn move, and svn delete can operate directly on repository URLs as well as on working copy paths. Of course, as previously mentioned, svn import always makes direct changes to the repository.

There are pros and cons to performing URL-based operations. One obvious advantage to doing so is speed: sometimes, checking out a working copy that you don't already have solely to perform some seemingly simple action is an overbearing cost. A disadvantage is that you are generally limited to a single, or single type of, operation at a time when operating directly on URLs. Finally, the primary advantage of a working copy is in its utility as a sort of “staging area” for changes. You can make sure that the changes you are about to commit make sense in the larger scope of your project before committing them. And, of course, these staged changes can be as complex or as a simple as they need to be, yet result in but a single new revision when committed.

4.3. 检查你的修改

Once you've finished making changes, you need to commit them to the repository, but before you do so, it's usually a good idea to take a look at exactly what you've changed. By examining your changes before you commit, you can compose a more accurate log message (a human-readable description of the committed changes stored alongside those changes in the repository). You may also discover that you've inadvertently changed a file, and that you need to undo that change before committing. Additionally, this is a good opportunity to review and scrutinize changes before publishing them. You can see an overview of the changes you've made by using the svn status command, and you can dig into the details of those changes by using the svn diff command.

看！没有网络！

You can use the commands svn status, svn diff, and svn revert without any network access even if your repository is across the network. This makes it easy to manage and review your changes-in-progress when you are working offline or are otherwise unable to contact your repository over the network.

Subversion does this by keeping private caches of pristine, unmodified versions of each versioned file inside its working copy administrative areas. This allows Subversion to report—and revert—local modifications to those files without network access. This cache (called the text-base) also allows Subversion to send the user's local modifications during a commit to the server as a compressed delta (or “difference”) against the pristine version. Having this cache is a tremendous benefit—even if you have a fast Internet connection, it's generally much faster to send only a file's changes rather than the whole file to the server.

4.3.1. 查看你的修改概况

To get an overview of your changes, use the svn status command. You'll probably use svn status more than any other Subversion command.

	提示
	Because the cvs status command's output was so noisy, and because cvs update not only performs an update, but also reports the status of your local changes, most CVS users have grown accustomed to using cvs update to report their changes. In Subversion, the update and status reporting facilities are completely separate. See 第 4 节 “区分状态和更新” for more details.

If you run svn status at the top of your working copy with no additional arguments, it will detect and report all file and tree changes you've made.

$ svn status
?       scratch.c
A       stuff/loot
A       stuff/loot/new.c
D       stuff/old.c
M       bar.c
$

In its default output mode, svn status prints seven columns of characters, followed by several whitespace characters, followed by a file or directory name. The first column tells the status of a file or directory and/or its contents. Some of the most common codes that svn status displays are:

? item: The file, directory, or symbolic link item is not under version control.
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 的“长形式”。第一列的含义不变，第二列显示工作版本号。第三列和第四列显示最后一次修改的版本号和修改者。

None of the prior invocations to svn status contact the repository—they merely report what is known about the working copy items based on the records stored in the working copy administrative area and on the timestamps and contents of modified files. But sometimes it is useful to see which of the items in your working copy have been modified in the repository since the last time you updated your working copy. For this, svn status offers the --show-updates (-u) option, which contacts the repository and adds information about items that are out of date:

$ 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

Notice in the previous example the two asterisks: if you were to run svn update at this point, you would receive changes to README and trout.c. This tells you some very useful information—because one of those items is also one that you have locally modified (the file README), you'll need to update and get the servers changes for that file before you commit, or the repository will reject your commit for being out of date. We discuss this in more detail later.

svn status can display much more information about the files and directories in your working copy than we've shown here—for an exhaustive description of svn status and its output, run svn help status or see svn status (stat, st).

4.3.2. 检查你的本地修改的详情

Another way to examine your changes is with the svn diff command, which displays differences in file content. When you run svn diff at the top of your working copy with no arguments, Subversion will print the changes you've made to human-readable files in your working copy. It displays those changes in unified diff format, a format which describes changes as “hunks” (or “snippets”) of a file's content where each line of text is prefixed with a single-character code: a space, which means the line was unchanged; a minus sign (-), which means the line was removed from the file; or a plus sign (+), which means the line was added to the file. In the context of svn diff, those minus-sign- and plus-sign-prefixed lines show how the lines looked before and after your modifications, respectively.

举例如下:

$ 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.

The svn diff command produces this output by comparing your working files against its pristine text-base. Files scheduled for addition are displayed as files in which every line was added; files scheduled for deletion are displayed as if every line was removed from those files. The output from svn diff is compatible with the patch program. The patch program reads and applies patch files (or “patches”), which are files that describe differences made to one or more files. Because of this, you can share the changes you've made in your working copy with someone else without first committing those changes by creating a patch file from the redirected output of svn diff:

$ svn diff > patchfile
$

Subversion uses its internal diff engine, which produces unified diff format, by default. If you want diff output in a different format, specify an external diff program using --diff-cmd and pass any additional flags that it needs via the --extensions (-x) option. For example, you might want Subversion to defer its difference calculation and display to the GNU diff program, asking that program to print local modifications made to the file foo.c in context diff format (another flavor of difference format) while ignoring changes made only to the case of the letters used in the file's contents:

$ svn diff --diff-cmd /usr/bin/diff -x "-i" foo.c
…
$

4.4. 修正错误

Suppose while viewing the output of svn diff you determine that all the changes you made to a particular file are mistakes. Maybe you shouldn't have changed the file at all, or perhaps it would be easier to make different changes starting from scratch. You could edit the file again and unmake all those changes. You could try to find a copy of how the file looked before you changed it, and then copy its contents atop your modified version. You could attempt to apply those changes to the file again in reverse using patch -R. And there are probably other approaches you could take.

Fortunately in Subversion, undoing your work and starting over from scratch doesn't require such acrobatics. Just use the svn revert command:

$ svn status README
M       README
$ svn revert README
Reverted 'README'
$ svn status README
$

In this example, Subversion has reverted the file to its premodified state by overwriting it with the pristine version of the file cached in the text-base area. But note that svn revert can undo any scheduled operation—for example, you might decide that you don't want to add a new file after all:

$ svn status new-file.txt
?       new-file.txt
$ svn add new-file.txt
A         new-file.txt
$ svn revert new-file.txt
Reverted 'new-file.txt'
$ svn status new-file.txt
?       new-file.txt
$

或许你不小心删除了一个文件：

$ svn status README
$ svn delete README
D         README
$ svn revert README
Reverted 'README'
$ svn status README
$

The svn revert command offers salvation for imperfect people. It can save you huge amounts of time and energy that would otherwise be spent manually unmaking changes or, worse, disposing of your working copy and checking out a fresh one just to have a clean slate to work with again.

4.5. 解决冲突

We've already seen how svn status -u can predict conflicts, but dealing with those conflicts is still something that remains to be done. Conflicts can occur any time you attempt to merge or integrate (in a very general sense) changes from the repository into your working copy. By now you know that svn update creates exactly that sort of scenario—that command's very purpose is to bring your working copy up to date with the repository by merging all the changes made since your last update into your working copy. So how does Subversion report these conflicts to you, and how do you deal with them?

Suppose you run svn update and you see this sort of interesting output:

$ svn update
U    INSTALL
G    README
Conflict discovered in 'bar.c'.
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options:

The U (which stands for “Updated”) and G (for “merGed”) codes are no cause for concern; those files cleanly absorbed changes from the repository. A file marked with U contains no local changes but was updated with changes from the repository. One marked with G had local changes to begin with, but the changes coming from the repository didn't overlap with those local changes.

It's the next few lines which are interesting. First, Subversion reports to you that in its attempt to merge outstanding server changes into the file bar.c, it has detected that some of those changes clash with local modifications you've made to that file in your working copy but have not yet committed. Perhaps someone has changed the same line of text you also changed. Whatever the reason, Subversion instantly flags this file as being in a state of conflict. It then asks you what you want to do about the problem, allowing you to interactively choose an action to take toward resolving the conflict. The most commonly used options are displayed, but you can see all of the options by typing s:

…
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options: s

  (e)  edit             - change merged file in an editor
  (df) diff-full        - show all changes made to merged file
  (r)  resolved         - accept merged version of file

  (dc) display-conflict - show all conflicts (ignoring merged version)
  (mc) mine-conflict    - accept my version for all conflicts (same)
  (tc) theirs-conflict  - accept their version for all conflicts (same)

  (mf) mine-full        - accept my version of entire file (even non-conflicts)
  (tf) theirs-full      - accept their version of entire file (same)

  (p)  postpone         - mark the conflict to be resolved later
  (l)  launch           - launch external tool to resolve conflict
  (s)  show all         - show this list

Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options:

在我们详细查看每个选项含义之前，让我们简短的回顾一下所有这些选项。

(e) edit: 用你喜欢的编辑器打开冲突的文件，编辑器是环境变量EDITOR设置的。
(df) diff-full: 使用标准区别格式显示base修订版本和冲突文件本身的区别。
(r) resolved: 完成文件编辑之后，通知 svn 你已经解决了文件的冲突，它应该接受当前的内容—从本质上讲就是你已经“解决了”冲突。
(dc) display-conflict: Display all conflicting regions of the file, ignoring changes which were successfully merged.
(mc) mine-conflict: Discard any newly received changes from the server which conflict with your local changes to the file under review. However, accept and merge all non-conflicting changes received from the server for that file.
(tc) theirs-conflict: Discard any local changes which conflict with incoming changes from the server for the file under review. However, preserve all non-conflicting local changes to that file.
(mf) mine-full: Discard all newly received changes from the server for the file under review, but preserve all your local changes for that file.
(tf) theirs-full: Discard all your local changes to the file under review and use only the newly received changes from the server for that file.
(p) postpone: 让文件在更新完成之后保持冲突状态。
(l) launch: 启动外部程序来执行冲突解决，这需要一些预先的准备。
(s) show all: 显示所有在冲突解决时可能使用的命令。

我们现在会更详细的覆盖这些命令，根据关联功能对其进行分组。

4.5.1. 交互式的查看冲突区别

Before deciding how to attack a conflict interactively, odds are that you'd like to see exactly what is in conflict. Two of the commands available at the interactively conflict resolution prompt can assist you here. The first is the “diff-full” command (df), which displays all the local modifications to the file in question plus any conflict regions:

…
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options: df
--- .svn/text-base/sandwich.txt.svn-base      Tue Dec 11 21:33:57 2007
+++ .svn/tmp/tempfile.32.tmp     Tue Dec 11 21:34:33 2007
@@ -1 +1,5 @@
-Just buy a sandwich.
+<<<<<<< .mine
+Go pick up a cheesesteak.
+=======
+Bring me a taco!
+>>>>>>> .r32
…

The first line of the diff content shows the previous contents of the working copy (the BASE revision), the next content line is your change, and the last content line is the change that was just received from the server (usually the HEAD revision).

The second command is similar to the first, but the “display-conflict” (dc) command shows only the conflict regions, not all the changes made to the file. Additionally, this command uses a slightly different display format for the conflict regions which allows you to more easily compare the file's contents in those regions as they would appear in each of three states: original and unedited; with your local changes applied and the server's conflicting changes ignored; and with only the server's incoming changes applied and your local, conflicting changes reverted.

After reviewing the information provided by these commands, you're ready to move on to the next action.

4.5.2. 交互式的解决冲突区别

There are several different ways to resolve conflicts interactively—two of which allow you to selectively merge and edit changes, the rest of which allow you to simply pick a version of the file and move along.

If you wish to choose some combination of your local changes, you can use the “edit” command (e) to manually edit the file with conflict markers in a text editor (configured per the instructions in 第 3 节 “使用外置编辑器”). After you've edited the file, if you're satisfied with the changes you've made, you can tell Subversion that the edited file is no longer in conflict by using the “resolve” command (r).

Regardless of what your local Unix snob will likely tell you, editing the file by hand in your favorite text editor is a somewhat low-tech way of remedying conflicts (see 第 4.5.4 节 “手工合并冲突” for a walkthrough). For this reason, Subversion provides the “launch” resolution command (l) to fire up a fancy graphical merge tool instead (see 第 4.3 节 “External merge”).

如果你决定不需要合并任何变更，而只是接受某个版本的文件，你可以通过 “mine-full” 命令(mf)选择你的修改(也称为 “mine”)或使用 “theirs-full” 命令(tf)选择别人的。

Finally, there is also a pair of compromise options available. The “mine-conflict” (mc) and “theirs-conflict” (tc) commands instruct Subversion to select your local changes or the server's incoming changes, respectively, as the “winner” for all conflicts in the file. But, unlike the “mine-full” and “theirs-full” commands, these commands preserve both your local changes and changes received from the server in regions of the file where no conflict was detected.

4.5.3. 延后解决冲突

This may sound like an appropriate section for avoiding marital disagreements, but it's actually still about Subversion, so read on. If you're doing an update and encounter a conflict that you're not prepared to review or resolve, you can type p to postpone resolving a conflict on a file-by-file basis when you run svn update. If you know in advance that you don't want to resolve any conflicts interactively, you can pass the --non-interactive option to svn update, and any file in conflict will be marked with a C automatically.

The C (for “Conflicted”) means that the changes from the server overlapped with your own, and now you have to manually choose between them after the update has completed. When you postpone a conflict resolution, svn typically does three things to assist you in noticing and resolving that conflict:

Subversion 在更新时打印 C 标记，并且标记这个文件处于冲突状态。
如果Subversion认为这个文件是可以合并的，它会置入冲突标记—特殊的横线分开冲突的“两面”—在文件里可视化的描述重叠的部分(Subversion 使用 svn:mime-type 属性来决定一个文件是否可以使用基于上下文的，以行为基础的合并，更多信息可以参见第 4.1 节 “文件内容类型”。)
对于每一个冲突的文件，Subversion放置三个额外的未版本化文件到你的工作副本：

filename.mine

This is your file as it existed in your working copy before you began the update process. This version of the file contains your local modifications as well as conflict markers. (If Subversion considers the file to be unmergeable, the .mine file isn't created, since it would be identical to the working file.)

filename.rOLDREV

This is the file as it existed in the BASE revision—that is, the unmodified revision of the file in your working copy before you began the update process—where OLDREV is that base revision number.

filename.rNEWREV

This is the file that your Subversion client just received from the server via the update of your working copy, where NEWREV corresponds to the revision number to which you were updating (HEAD, unless otherwise requested).

举一个例子，Sally 修改了 sandwich.txt，还没有提交。这时候，Harry 提交了他对这个文件的修改。Sally 在提交之前更新她的工作副本，得到了冲突，她选择了延迟解决冲突：

$ svn update
Conflict discovered in 'sandwich.txt'.
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options: p
C    sandwich.txt
Updated to revision 2.
Summary of conflicts:
  Text conflicts: 1
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2

在这种情况下，Subversion 不会允许 Sally 提交 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

如果你延迟解决冲突，你需要在 Subversion 允许你提交你的修改之前解决冲突。你可以通过 svn resolve 命令和 --accept 选项的多个参数之中的一个来完成。

如果你希望选择上次检出后修改之前的文件版本，选择 base 参数。

如果你希望选择只包含你修改的版本，选择 mine-full 参数。

如果你希望选择最近从服务器更新的版本(因此会丢弃你的所有编辑)，选择 theirs-full 参数。

然而，如果你想在自己的修改与服务器端的修改之间部分选择的话，请“手工”合并冲突文本(检查和编辑文件中的冲突标记)，然后选择参数 working 。

svn resolve 删除这三个临时文件，使用 --accept 选项指定的文件版本，从而 Subversion 不会再认为文件处于冲突状态。

$ svn resolve --accept working sandwich.txt
Resolved conflicted state of 'sandwich.txt'

4.5.4. 手工合并冲突

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

这里一个简单的例子。由于不良的交流，你和同事 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

Usually you won't want to just delete the conflict markers and Sally's changes—she's going to be awfully surprised when the sandwich arrives and it's not what she wanted. This is where you pick up the phone or walk across the office and explain to Sally that you can't get sauerkraut from an Italian deli.^[7] Once you've agreed on the changes you will commit, edit your file and remove the conflict markers:

Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread

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

$ svn resolve --accept working sandwich.txt
Resolved conflicted state of 'sandwich.txt'
$ svn commit -m "Go ahead and use my sandwich, discarding Sally's edits."

注意 svn resolve 不像我们本章学过的其他命令一样需要参数。在任何情况下，当你认为解决了冲突的时候，需要小心运行svn resolve—一旦删除了临时文件，Subversion 会允许你提交这些文件，即使文件中还存在冲突标记。

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

4.5.5. 丢弃你的修改而接收新获取的修订版本

如果你遇到冲突，决定丢弃你的修改，你可以运行 svn resolve --accept theirs-full CONFLICTED-PATH ， Subversion 会丢弃你做的修改，并且删除临时文件：

$ svn update
Conflict discovered in 'sandwich.txt'.
Select: (p) postpone, (df) diff-full, (e) edit,
        (mc) mine-conflict, (tc) theirs-conflict,
        (s) show all options: p
C    sandwich.txt
Updated to revision 2.
Summary of conflicts:
  Text conflicts: 1
$ ls sandwich.*
sandwich.txt  sandwich.txt.mine  sandwich.txt.r2  sandwich.txt.r1
$ svn resolve --accept theirs-full sandwich.txt
Resolved conflicted state of 'sandwich.txt'
$

4.5.6. Punting: using svn revert

如果你决定丢弃自己的修改,并且重新开始编辑(无论是发生在冲突之后，还是其它情况)，只需撤销你的修改：

$ svn revert sandwich.txt
Reverted 'sandwich.txt'
$ ls sandwich.*
sandwich.txt
$

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

4.6. 提交你的修改

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

The svn commit command sends all of your changes to the repository. When you commit a change, you need to supply a log message describing your change. Your log message will be attached to the new revision you create. If your log message is brief, you may wish to supply it on the command line using the --message (-m) option:

$ svn commit -m "Corrected number of cheese slices."
Sending        sandwich.txt
Transmitting file data .
Committed revision 3.

However, if you've been composing your log message in some other text file as you work, you may want to tell Subversion to get the message from that file by passing its filename as the value of the --file (-F) option:

$ svn commit -F logmsg
Sending        sandwich.txt
Transmitting file data .
Committed revision 4.

如果你没有使用 --message (-m 或者 --file (-F) 选项， Subversion 会自动启动你喜欢的编辑器(参见第 1.3.2 节 “配置”中的 editor-cmd 部分)来编辑日志信息。

	提示
	If you're in your editor writing a commit message and decide that you want to cancel your commit, you can just quit your editor without saving changes. If you've already saved your commit message, simply delete all the text, save again, and then abort: $ svn commit Waiting for Emacs...Done Log message unchanged or not specified (a)bort, (c)ontinue, (e)dit a $

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

$ svn commit -m "Add another rule"
Sending        rules.txt
svn: Commit failed (details follow):
svn: File '/sandwich.txt' is out of date
…

(错误信息的精确措辞依赖于网络协议和你使用的服务器，但对于所有的情况，其思想完全一样。)

此刻，你需要运行 svn update 来处理所有的合并和冲突，然后再尝试提交。

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

^[6]Of course, nothing is ever totally deleted from the repository—just from its HEAD revision. You may continue to access the deleted item in previous revisions. Should you desire to resurrect the item so that it is again present in HEAD, see 第 3.6 节 “找回删除的项目”.

^[7]如果你向他们询问，他们非常有理由把你带到城外的铁轨上。

上一页	上一级	下一页
3. 创建工作副本	起始页	5. 检验历史