[svnbook commit] r1510 - trunk/src/zh/book
rocksun
svnbook-dev at red-bean.com
Fri Jul 1 12:36:58 CDT 2005
Author: rocksun
Date: Fri Jul 1 12:36:56 2005
New Revision: 1510
Modified:
trunk/src/zh/book/ch05.xml
trunk/src/zh/book/glossary.xml
Log:
* zh/book/ch05.xml: Add UTF BOM, svn-ch-5-sect-3.6 Finished.
* zh/book/glossary.xml: add some new word
Modified: trunk/src/zh/book/ch05.xml
==============================================================================
--- trunk/src/zh/book/ch05.xml (original)
+++ trunk/src/zh/book/ch05.xml Fri Jul 1 12:36:56 2005
@@ -1,4 +1,4 @@
-<chapter id="svn-ch-5">
+<chapter id="svn-ch-5">
<title>Repository Administration</title>
<simplesect>
@@ -2470,139 +2470,42 @@
<!-- ***************************************************************** -->
<sect2 id="svn-ch-5-sect-3.6">
- <title>Repository Backup</title>
+ <title>版本库备份</title>
- <para>Despite numerous advances in technology since the birth of
- the modern computer, one thing unfortunately rings true with
- crystalline clarity—sometimes, things go very, very
- awry. Power outages, network connectivity dropouts, corrupt
- RAM and crashed hard drives are but a taste of the evil that
- Fate is poised to unleash on even the most conscientious
- administrator. And so we arrive at a very important
- topic—how to make backup copies of your repository
- data.</para>
+ <para>尽管现代计算机的诞生带来了许多便利，但有一件事听起来是完全正确的—有时候，事情变的糟糕，很糟糕，动力损耗、网络中断、坏掉的内存和损坏的硬盘都是对魔鬼的一种体验，即使对于最尽职的管理员，命运也早已注定。所以我们来到了这个最重要的主题—怎样备份你的版本库数据。</para>
+
+ <para>Subversion版本库管理员通常有两种备份方式—增量的和完全的。我们在早先的章节曾经讨论过如何使用<command>svnadmin dump --incremental</command>命令执行增量备份（见<xref
+ linkend="svn-ch-5-sect-3.5"/>），从本质上讲，这个方法只是备份了从你上次备份版本库到现在的变化。</para>
+
+ <para>一个完全的版本库备份照字面上讲就是对整个版本库目录的复制（包括伯克利数据库或者文件FSFS环境），现在，除非你临时关闭了其他对版本库的访问，否则仅仅做一次迭代的拷贝会有产生错误备份的风险，因为有人可能会在并行的写数据库。</para>
- <para>There are generally two types of backup methods available
- for Subversion repository administrators—incremental and
- full. We discussed in an earlier section of this chapter how
- to use <command>svnadmin dump --incremental</command> to
- perform an incremental backup (see <xref
- linkend="svn-ch-5-sect-3.5"/>). Essentially, the idea is to
- only backup at a given time the changes to the repository
- since the last time you made a backup.</para>
-
- <para>A full backup of the repository is quite literally a
- duplication of the entire repository directory (which includes
- either Berkeley database or FSFS environment). Now, unless
- you temporarily disable all other access to your repository,
- simply doing a recursive directory copy runs the risk of
- generating a faulty backup, since someone might be currently
- writing to the database.</para>
-
- <para>In the case of Berkeley DB, Sleepycat documents describe a
- certain order in which database files can be copied that will
- guarantee a valid backup copy. And a similar ordering exists
- for FSFS data. Better still, you don't have to implement
- these algorithms yourself, because the Subversion development
- team has already done so. The
- <command>hot-backup.py</command> script is found in the
- <filename>tools/backup/</filename> directory of the Subversion
- source distribution. Given a repository path and a backup
- location, <command>hot-backup.py</command>—which is
- really just a more intelligent wrapper around the
- <command>svnadmin hotcopy</command> command—will perform
- the necessary steps for backing up your live
- repository—without requiring that you bar public
- repository access at all—and then will clean out the
- dead Berkeley log files from your live repository.</para>
-
- <para>Even if you also have an incremental backup, you might
- want to run this program on a regular basis. For example, you
- might consider adding <command>hot-backup.py</command> to a
- program scheduler (such as <command>cron</command> on Unix
- systems). Or, if you prefer fine-grained backup solutions,
- you could have your post-commit hook script call
- <command>hot-backup.py</command> (see <xref
- linkend="svn-ch-5-sect-2.1" />), which will then cause a new
- backup of your repository to occur with every new revision
- created. Simply add the following to the
- <filename>hooks/post-commit</filename> script in your live
- repository directory:</para>
+ <para>如果是伯克利数据库，恼人的文档描述了保证安全拷贝的步骤，对于FSFS的数据，也有类似的顺序。我们有更好的选择，我们不需要自己去实现这个算法，因为Subversion开发小组已经为你实现了这些算法。Subversion源文件分发版本的<filename>tools/backup/</filename>目录有一个<command>hot-backup.py</command>文件，给定版本库路径和备份路径，<command>hot-backup.py</command>—是一个包裹了<command>svnadmin hotcopy</command>但更加智能的命令—将会执行必要的步骤来备份你的活动的版本库—不需要你首先禁止公共的版本库访问—而且之后会从你的版本库清理死掉的伯克利日志文件。</para>
+
+ <para>
+ 甚至当你用了一个增量备份时，你也会希望有计划的运行这个程序。举个例子，你考虑在你的程序调度程序（如Unix下的<command>cron</command>）里加入<command>hot-backup.py</command>，或者你喜欢更加细致的备份解决方案，你可以让你的post-commit的钩子脚本执行<command>hot-backup.py</command>（见see <xref
+ linkend="svn-ch-5-sect-2.1" />），这样会导致你的版本库的每次提交执行一次备份，只要在你的<filename>hooks/post-commit</filename>脚本里添加如下代码：</para>
<programlisting>
(cd /path/to/hook/scripts; ./hot-backup.py ${REPOS} /path/to/backups &)
</programlisting>
- <para>The resulting backup is a fully functional Subversion
- repository, able to be dropped in as a replacement for your
- live repository should something go horribly wrong.</para>
-
- <para>There are benefits to both types of backup methods. The
- easiest is by far the full backup, which will always result in
- a perfect working replica of your repository. This again
- means that should something bad happen to your live
- repository, you can restore from the backup with a simple
- recursive directory copy. Unfortunately, if you are
- maintaining multiple backups of your repository, these full
- copies will each eat up just as much disk space as your live
- repository.</para>
+ <para>作为结果的备份是一个完全功能的版本库，当发生严重错误时可以作为你的活动版本库的替换。</para>
- <para>Incremental backups using the repository dump format are
- excellent to have on hand if the database schema changes
- between successive versions of Subversion itself. Since a
- complete repository dump and load are generally required to
- upgrade your repository to the new schema, it's very
- convenient to already have half of that process (the dump
- part) finished. Unfortunately, the creation of—and
- restoration from—incremental backups takes longer, as
- each commit is effectively replayed into either the dump file
- or the repository.</para>
-
- <para>In either backup scenario, repository administrators need
- to be aware of how modifications to unversioned revision
- properties affect their backups. Since these changes do not
- themselves generate new revisions, they will not trigger
- post-commit hooks, and may not even trigger the
- pre-revprop-change and post-revprop-change hooks.
- <footnote>
- <para><command>svnadmin setlog</command> can be called in a
- way that bypasses the hook interface altogether.</para>
- </footnote>
- And since you can change revision properties without respect
- to chronological order—you can change any revision's
- properties at any time—an incremental backup of the
- latest few revisions might not catch a property modification
- to a revision that was included as part of a previous
- backup.</para>
-
- <para>Generally speaking, only the truly paranoid would need to
- backup their entire repository, say, every time a commit
- occurred. However, assuming that a given repository has some
- other redundancy mechanism in place with relatively fine
- granularity (like per-commit emails), a hot backup of the
- database might be something that a repository administrator
- would want to include as part of a system-wide nightly backup.
- For most repositories, archived commit emails alone provide
- sufficient redundancy as restoration sources, at least for the
- most recent few commits. But it's your data—protect it
- as much as you'd like.</para>
-
- <para>Often, the best approach to repository backups is a
- diversified one. You can leverage combinations of full and
- incremental backups, plus archives of commit emails. The
- Subversion developers, for example, back up the Subversion
- source code repository after every new revision is created,
- and keep an archive of all the commit and property change
- notification emails. Your solution might be similar, but
- should be catered to your needs and that delicate balance of
- convenience with paranoia. And while all of this might not
- save your hardware from the iron fist of Fate,
+ <para>两种备份方式都有各自的有点，最简单的方式是完全备份，将会每次建立版本库的完美复制品，这意味着如果当你的活动版本库发生了什么事情，你可以用备份恢复。但不幸的是，如果你维护多个备份，每个完全的备份会吞噬掉和你的活动版本库同样的空间。</para>
+
+ <para>增量备份会使用的版本库导出格式在Subversion的数据库模式改变时非常完美，因此当我们升级Subversion数据库模式的时候，一个完整的版本库导出和导入是必须的，做一半工作非常的容易（导出部分），不幸的是，增量备份的创建和恢复会占用很长时间，因为每一次提交都会被重放，对于导出文件和版本库。</para>
+
+ <para>在每一种备份情境下，版本库管理员需要意识到对未版本化的修订版本属性对备份的影响，因为这些修改本身不会产生新的修订，他们不会触发post-commit触发器的钩子程序，也不会触发pre-revprop-change和post-revprop-change的钩子。
<footnote>
- <para>You know—the collective term for all of her
- <quote>fickle fingers</quote>.</para>
+ <para><command>svnadmin setlog</command>可以被绕过钩子程序被调用。</para>
+ </footnote> 而且因为你可以改变修订版本的属性，而不需要遵照时间顺序—你可在任何时刻是修改任何修订版本的属性—因此最新版本的增量备份不会捕捉到以前特定修订版本的属性修改。</para>
+
+ <para>通常说来，在每次提交时，只有妄想狂才会备份整个版本库，然而，假设一个给定的版本库拥有一些恰当粒度得冗余机制（如每次提交的邮件），版本库管理员也许会希望将版本库的热备份引入到系统级的每夜备份，对大多数版本库，归档的提交邮件为保存资源提供了足够的冗余措施，至少对于最近的提交。但是它是你的数据—你喜欢怎样保护都可以。</para>
+
+ <para>经常的，最好的版本库备份方式是混合的，你可以平衡完全和增量备份，另外配合提交邮件的归档，Subversion开发者，举个例子，在每个新的修订版本建立时备份Subversion的源代码版本库，并且保留所有的提交和属性修改通知文件。你的解决方案类似，必须迎合你的需要，平衡便利和你的偏执。然而这些不会改变你的硬件来自钢铁的命运。<footnote> <para>你知道的— 所有的术语只是她的
+ <quote>变幻无常的手指</quote>.</para>
</footnote>
- it should certainly help you recover from those trying
- times.</para>
+ 这一定会帮助你减少尝试的时间。</para>
</sect2>
</sect1>
@@ -2612,9 +2515,10 @@
<!-- *** SECTION 6: ADDING PROJECTS *** -->
<!-- ******************************************************************* -->
<sect1 id="svn-ch-5-sect-6">
- <title>Adding Projects</title>
+ <title>添加项目</title>
- <para>Once your repository is created and configured, all that
+ <para>一旦你的版本库已经建立并且配置好了，剩下的就是使用了。
+ Once your repository is created and configured, all that
remains is to begin using it. If you have a collection of
existing data that is ready to be placed under version control,
you will more than likely want to use the <command>svn</command>
Modified: trunk/src/zh/book/glossary.xml
==============================================================================
--- trunk/src/zh/book/glossary.xml (original)
+++ trunk/src/zh/book/glossary.xml Fri Jul 1 12:36:56 2005
@@ -3,6 +3,23 @@
<title>术语表</title>
<glossary>
+ <glossdiv>
+ <title>A</title>
+ <glossentry>
+ <glossterm>administrative subdirectory （管理目录）</glossterm>
+ <glossdef>
+ <para>通常是工作目录中的<filename>.svn</filename>目录，保存了帮助Subversion工作的文件。
+ </para>
+ </glossdef>
+ </glossentry>
+ <glossentry>
+ <glossterm>administrative area （管理区域）</glossterm>
+ <glossdef>
+ <para>管理目录的一种更抽象的说法。
+ </para>
+ </glossdef>
+ </glossentry>
+ </glossdiv>
<glossdiv>
<title>B</title>
@@ -41,6 +58,18 @@
</glossdiv>
<glossdiv>
+ <title>D</title>
+
+ <glossentry>
+ <glossterm>dump format（导出格式）</glossterm>
+
+ <glossdef>
+ <para>从版本库里导出的文件的一种格式。</para>
+ </glossdef>
+ </glossentry>
+ </glossdiv>
+
+ <glossdiv>
<title>R</title>
<glossentry>
More information about the svnbook-dev
mailing list