refector: part6-9: remove spaces, add line wraps

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

06-migrate/025-svn.rst

@@ -1,64 +1,88 @@
 SVN版本库到Git的迁移
 =====================
 
-Subversion 版本库到 Git 版本库的转换，最好的方法就是 git-svn。而 git-svn 的使用方法在前面 “Git 和 SVN 协同模型” 一章已经详细介绍过。本章的内容将不再对 git-svn 的用法做过多的重复，只在这里强调一下版本库迁移时的注意事项，相关 git-svn 内容还请参照前面的内容。
+Subversion版本库到Git版本库的转换，最好的方法就是git-svn。而git-svn的使\
+用方法在前面“Git和SVN协同模型”一章已经详细介绍过。本章的内容将不再对\
+git-svn的用法做过多的重复，只在这里强调一下版本库迁移时的注意事项，相关\
+git-svn内容还请参照前面的内容。
 
-在迁移之前要确认一个问题，Subversion 转换到 Git 库之后，Subversion 还继续使用么？意思是说还允许向 Subversion 提交么？
+在迁移之前要确认一个问题，Subversion转换到Git库之后，Subversion还继续使\
+用么？意思是说还允许向Subversion提交么？
 
-如果回答是，那么直接查看 “Git 和 SVN 协同模型” 一章，用 Git 作为前端工具来操作 Subversion 版本库，而不要理会下面的内容。因为下面描述的迁移步骤针对的是一次性的 Subversion 到 Git 版本库的迁移。
+如果回答是，那么直接查看“Git和SVN协同模型”一章，用Git作为前端工具来操作\
+Subversion版本库，而不要理会下面的内容。因为下面描述的迁移步骤针对的是\
+一次性的Subversion到Git版本库的迁移。
 
-**需要提交中出现 git-svn-id 标识么？**
+**需要提交中出现git-svn-id标识么？**
 
-如果一次性、永久性的将 Subverison 迁移到 Git 库，可以选择 `git-svn-id:` 标识不在转换后 Git 的提交日志中出现，这样转换后的 Git 库根本看不出来曾经用 Subversion 版本库维护过。
+如果一次性、永久性的将Subverison迁移到Git库，可以选择\ ``git-svn-id:``\
+标识不在转换后Git的提交日志中出现，这样转换后的Git库根本看不出来曾经用\
+Subversion版本库维护过。
 
-在 git-svn 的 `clone` 或者 `init` 子命令行中使用参数： `--no-metadata` 。Git 库的配置会自动配置 svn-remote.noMetadata 为 1。之后执行 `git svn fetch` 时就不会在日志中产生 `git-svn-id:` 的标识。
+在git-svn的\ ``clone``\ 或者\ ``init``\ 子命令行中使用参数：\
+``--no-metadata``\ 。Git库的配置会自动配置\ ``svn-remote.noMetadata``\
+为1。之后执行\ :command:`git svn fetch`\ 时就不会在日志中产生\
+``git-svn-id:``\ 的标识。
 
-**Subversion 用户名到 Git 用户名的映射**
+**Subversion用户名到Git用户名的映射**
 
-缺省转换后 Git 库的提交者 ID 为如下格式： `userid <userid@SVN-REPOS-UUID>` 。即在邮件地址域名处以 SVN 版本库的 UUID 代替。可以在执行 `git svn fetch` 时通过下面的参数提供一个映射文件完成 SVN 用户名到 Git 用户名的转换。
+缺省转换后Git库的提交者ID为如下格式：\ ``userid <userid@SVN-REPOS-UUID>``\ 。\
+即在邮件地址域名处以SVN版本库的UUID代替。可以在执行\ :command:`git svn fetch`\
+时通过下面的参数提供一个映射文件完成SVN用户名到Git用户名的转换。
 
-  ::
+::
 
-    -A<filename>, --authors-file=<filename>
+  -A<filename>, --authors-file=<filename>
 
-即用 `-A` 或者 `--authors-file` 参数给出一个映射文件，这个文件帮助 git-svn 将 Subversion 用户名映射为 Git 用户名。此文件的每一行定义一个用户名映射，每一行的格式为：
+即用\ ``-A``\ 或者\ ``--authors-file``\ 参数给出一个映射文件，这个文件帮\
+助git-svn将Subversion用户名映射为Git用户名。此文件的每一行定义一个用户名\
+映射，每一行的格式为：
 
-  ::
+::
 
-    loginname = User Name <user@example.com>
+  loginname = User Name <user@example.com>
 
-也可以通过下面的命令在 Git 库的 config 文件中设置，这样就不必在每次执行 `git svn fetch` 都带上这个参数。
+也可以通过下面的命令在Git库的\ :file:`config`\ 文件中设置，这样就不必在\
+每次执行\ :command:`git svn fetch`\ 都带上这个参数。
 
-  ::
+::
 
-    $ git config svn.authorsfile /path/to/authersfile
+  $ git config svn.authorsfile /path/to/authersfile
 
-当设定了用户映射文件后，如果在执行 `git svn fetch` 是发现 SVN 的用户在该映射文件中没有定义，转换过程被中断。需要重新编辑用户映射文件，补充新的用户映射后，再重新执行 git-svn 命令。
+当设定了用户映射文件后，如果在执行\ :command:`git svn fetch`\ 是发现SVN\
+的用户在该映射文件中没有定义，转换过程被中断。需要重新编辑用户映射文件，\
+补充新的用户映射后，再重新执行git-svn命令。
 
-**将Subversion分支和里程碑直接转换为 Git 分支和里程碑，不要放在 refs/remotes 下**
+**将Subversion分支和里程碑直接转换为Git分支和里程碑，不要放在\ ``refs/remotes``\ 下**
 
-使用缺省参数执行 SVN 到 Git 的转换时，SVN 的里程碑和分支转换到 Git 库的 `refs/remotes` 引用下。这会导致其他人从转换后的 Git 库克隆时，看不到 Subversion 原有的分支和里程碑。
+使用缺省参数执行SVN到Git的转换时，SVN的里程碑和分支转换到Git库的\
+``refs/remotes``\ 引用下。这会导致其他人从转换后的Git库克隆时，看不到\
+Subversion原有的分支和里程碑。
 
-当以缺省参数执行 `git svn init` 时，Git 的配置文件中会生成下面的配置：
+当以缺省参数执行\ :command:`git svn init`\ 时，Git的配置文件中会生成下面\
+的配置：
 
-  ::
+::
 
-    [svn-remote "svn"]
-            fetch = trunk:refs/remotes/trunk
-            branches = branches/*:refs/remotes/*
-            tags = tags/*:refs/remotes/tags/*
+  [svn-remote "svn"]
+          fetch = trunk:refs/remotes/trunk
+          branches = branches/*:refs/remotes/*
+          tags = tags/*:refs/remotes/tags/*
 
-可以直接编辑 Git 配置文件，将其内容调整如下：
+可以直接编辑Git配置文件，将其内容调整如下：
 
-  ::
+::
 
-    [svn-remote "svn"]
-            fetch = trunk:refs/heads/master
-            branches = branches/*:refs/heads/*
-            tags = tags/*:refs/tags/*
+  [svn-remote "svn"]
+          fetch = trunk:refs/heads/master
+          branches = branches/*:refs/heads/*
+          tags = tags/*:refs/tags/*
 
-之后再执行 `git svn fetch` 后，就可以实现 SVN 的分支和里程碑正确的转换为 Git 库的里程碑。否则就需要将 `.git/refs/remots/` 下的引用移动到 `.git/refs/heads` 以及 `.git/refs/tags` 下。
+之后再执行\ :command:`git svn fetch`\ 后，就可以实现SVN的分支和里程碑正\
+确的转换为Git库的里程碑。否则就需要将\ :file:`.git/refs/remots/`\ 下的引\
+用移动到\ :file:`.git/refs/heads`\ 以及\ :file:`.git/refs/tags`\ 下。
 
-**清除 git-svn 的中间文件**
+**清除git-svn的中间文件**
 
-git-svn 的中间文件位于目录 "`.git/svn`" 下，删除此目录完成对 git-svn 转换数据库文件的清理。
+git-svn的中间文件位于目录\ :file:`.git/svn`\ 下，删除此目录完成对git-svn\
+转换数据库文件的清理。

06-migrate/030-hg.rst

@@ -1,26 +1,46 @@
-Hg 版本库到Git的迁移
+Hg版本库到Git的迁移
 =====================
 
-Mercurial（水银）是和 Git 同时代的、与之齐名的一款著名的分布式版本控制系统，也有相当多的使用者。就像水银又名汞，作为版本控制系统的 Mercurial 又称作 Hg（水银元素符号）。Hg 具有简单易用的优点，至少 Hg 提交的顺序递增的数字编号让 Subversion 用户感到更为亲切。Hg 的开发语言除少部分因性能原因使用 C 语言外，大部分用 Python 语言开发完成，因而更易扩展，最终形成了 Hg 最具特色的插件系统。例如 MQ 就是 Hg 一个很有用的插件，通过 Quilt 式的补丁集实现对定制开发的特性分支的版本控制，当然 StGit 和 Topgit 也可以实现类似的功能。
-
-但是 Hg 存在一些不足。例如服务器的存储效率不能和 Git 相比，服务器存储空间占用更大。Hg 还不支持真正的分支，只能通过版本库克隆来进行分支开发。因为 Hg 不支持真正的分支，所以不能向 git-svn 那样完整的将 Subversion 版本库转换和互操作。Hg 的速度相比 Git 要慢，尤其是网络操作没有像 Git 一样精确的进度显示。Hg 提交只能回退一次，要想多次回退和整理版本库需要用到 MQ 插件。作为定制开发的利器 Hg+MQ 不适合多人协作开发而 Git+Topgit 更为适合。
-
-不论是何原因想从 Hg 迁移到 Git，用一个名为 fast-export 的转换工具可以很方便的实现。fast-export 是一个用 Python 开发的命令行工具，可以将本地的 Hg 版本库迁移为 Git 版本库。其原理和 CVS 版本库迁移至 Git 时使用的 cvs2git 相仿，都是先从源版本库生成导出文件，再用 Git 的通用版本库转换工具 git-fast-import 导入到新建的 Git 版本库中。
-
-安装 fast-export 非常简单，只要用 Git 克隆 fast-export 的版本库即可。
+Mercurial（水银）是和Git同时代的、与之齐名的一款著名的分布式版本控制系统，\
+也有相当多的使用者。就像水银又名汞，作为版本控制系统的Mercurial又称作Hg\
+（水银元素符号）。Hg具有简单易用的优点，至少Hg提交的顺序递增的数字编号让\
+Subversion用户感到更为亲切。Hg的开发语言除少部分因性能原因使用C语言外，\
+大部分用Python语言开发完成，因而更易扩展，最终形成了Hg最具特色的插件系\
+统。例如MQ就是Hg一个很有用的插件，通过Quilt式的补丁集实现对定制开发的特\
+性分支的版本控制，当然StGit和Topgit也可以实现类似的功能。
+
+但是Hg存在一些不足。例如服务器的存储效率不能和Git相比，服务器存储空间占\
+用更大。Hg还不支持真正的分支，只能通过版本库克隆来进行分支开发。因为Hg不\
+支持真正的分支，所以不能向git-svn那样完整的将Subversion版本库转换和互操\
+作。Hg的速度相比Git要慢，尤其是网络操作没有像Git一样精确的进度显示。Hg提\
+交只能回退一次，要想多次回退和整理版本库需要用到MQ插件。作为定制开发的利\
+器“Hg+MQ”不适合多人协作开发而“Git+Topgit”更为适合。
+
+不论是何原因想从Hg迁移到Git，用一个名为fast-export的转换工具可以很方便的\
+实现。fast-export是一个用Python开发的命令行工具，可以将本地的Hg版本库迁\
+移为Git版本库。其原理和CVS版本库迁移至Git时使用的cvs2git相仿，都是先从源\
+版本库生成导出文件，再用Git的通用版本库转换工具\
+:command:`git fast-import`\ 导入到新建的Git版本库中。
+
+安装fast-export非常简单，只要用Git克隆fast-export的版本库即可。
 
 ::
 
   $ cd /path/to
   $ git clone git://repo.or.cz/fast-export.git
 
-完成克隆后，会看到 :file:`/path/to/fast-export` 目录中有一个名为 `hg-fast-import.sh` 的脚本文件，该文件封装了对相应 Python 脚本的调用。使用该脚本可以实现 Hg 版本库到 Git 版本库的迁移。
+完成克隆后，会看到\ :file:`/path/to/fast-export`\ 目录中有一个名为\
+:file:`hg-fast-import.sh`\ 的脚本文件，该文件封装了对相应Python脚本的调用。\
+使用该脚本可以实现Hg版本库到Git版本库的迁移。
 
-下面就演示一下 Hg 版本库到 Git 版本库的转换。
+下面就演示一下Hg版本库到Git版本库的转换。
 
-* 要转换的 Hg 版本库位于路径 :file:`/path/to/hg/hello/.hg` 下。
+* 要转换的Hg版本库位于路径\ :file:`/path/to/hg/hello/.hg`\ 下。
 
-  Hg 不支持真正的分支，而且版本库中可能存在尚未合并的多个头指针。检查一下不要存在具有相同分支名但尚未合并的多个头指针，否则转换会失败。下面显示的该 Hg 版本库中具有两个具名分支 `r1.x` 和 `next` ，还有一个缺省未设置名称的头指针，因为分支名各不相同所以不会为转换过程造成麻烦。
+  Hg不支持真正的分支，而且版本库中可能存在尚未合并的多个头指针。检查一下\
+  不要存在具有相同分支名但尚未合并的多个头指针，否则转换会失败。下面显示\
+  的该Hg版本库中具有两个具名分支\ ``r1.x``\ 和\ ``next``\ ，还有一个缺省\
+  未设置名称的头指针，因为分支名各不相同所以不会为转换过程造成麻烦。
 
   ::
 
@@ -51,7 +71,7 @@ Mercurial（水银）是和 Git 同时代的、与之齐名的一款著名的分
     描述:
     Fixed #6: import new upstream version hello-2.0.0
 
-* 初始化一个 Git 版本库，该版本库就是迁移的目标版本库。
+* 初始化一个Git版本库，该版本库就是迁移的目标版本库。
 
   ::
 
@@ -60,13 +80,15 @@ Mercurial（水银）是和 Git 同时代的、与之齐名的一款著名的分
     $ git init
     Initialized empty Git repository in /path/to/my/workspace/hello/.git/
 
-* 在刚刚完成初始化的 Git 工作区中调用 `hg-fast-export.sh` 脚本完成版本库转换。
+* 在刚刚完成初始化的Git工作区中调用\ :file:`hg-fast-export.sh`\ 脚本完成\
+  版本库转换。
 
   ::
 
     $ /path/to/fast-export/hg-fast-export.sh -r /path/to/hg/hello
 
-* 转换完毕，执行 `git branch` 会看到 Hg 版本库中的具名分支都转换为相应的分支，没有命名的缺省头指针转换为 master 分支。
+* 转换完毕，执行\ :command:`git branch`\ 会看到Hg版本库中的具名分支都转\
+  换为相应的分支，没有命名的缺省头指针转换为master分支。
 
   ::
 
@@ -75,10 +97,14 @@ Mercurial（水银）是和 Git 同时代的、与之齐名的一款著名的分
       next
       r1.x
 
+在转换后的Git版本库目录中，保存了几个用于记录版本库转换进度的状态文件\
+（\ :file:`.git/hg2git-\*`\ ），当在Git工作区不带任何参数执行\
+:file:`hg-fast-export.sh`\ 命令时，会继续增量式的进行转换，将Hg版本库\
+中的新提交迁移到Git版本库中。
 
-在转换后的 Git 版本库目录中，保存了几个用于记录版本库转换进度的状态文件（.git/hg2git-\*），当在 Git 工作区不带任何参数执行 `hg-fast-export.sh` 命令时，会继续增量式的进行转换，将 Hg 版本库中的新提交迁移到 Git 版本库中。
-
-如果使用了多个不同的 Hg 克隆版本库进行分支管理，就需要一一对 Hg 版本库进行转换，然后在对转换后的 Git 版本库进行合并。在合并 Git 版本库的时候可以参考下面的命令。
+如果使用了多个不同的Hg克隆版本库进行分支管理，就需要一一对Hg版本库进行转\
+换，然后在对转换后的Git版本库进行合并。在合并Git版本库的时候可以参考下面\
+的命令。
 
 ::
 
@@ -87,4 +113,3 @@ Mercurial（水银）是和 Git 同时代的、与之齐名的一款著名的分
   $ git remote update
   $ git checkout -b <branch1> origin/<name1>/master
   $ git checkout -b <branch2> origin/<name2>/master
-