[svnbook] r5550 committed - branches/1.8/zh/book/ch05-repository-admin.xml

[wuzhouhui at users.sourceforge.net]

Revision: 5550
          http://sourceforge.net/p/svnbook/source/5550
Author:   wuzhouhui
Date:     2017-12-24 02:22:23 +0000 (Sun, 24 Dec 2017)
Log Message:
-----------
1.8/zh: translation of chapter 5 in progress

Modified Paths:
--------------
    branches/1.8/zh/book/ch05-repository-admin.xml

Modified: branches/1.8/zh/book/ch05-repository-admin.xml
===================================================================
--- branches/1.8/zh/book/ch05-repository-admin.xml	2017-12-23 09:48:05 UTC (rev 5549)
+++ branches/1.8/zh/book/ch05-repository-admin.xml	2017-12-24 02:22:23 UTC (rev 5550)
@@ -425,6 +425,7 @@
         是用一个单独的仓库存放这些项目, 还是每个项目一个仓库, 还是介于两者
         之间.</para>
 
+      <!--
       <para>There are benefits to using a single repository for
         multiple projects, most obviously the lack of duplicated
         maintenance.  A single repository means that there is one set
@@ -433,7 +434,14 @@
         version, and so on.  Also, you can move data between projects
         easily, without losing any historical versioning
         information.</para>
+      -->
+      <para>把多个项目放在一个单独的仓库里有一定的好处, 最明显的就是减少了
+        重复劳动. 一个单独的仓库意味着只有一个钩子集合, 需要例行备份的东西
+        只有一个, 如果 Subversion 发布了不兼容旧版的新版本, 只有一个仓库需
+        要转储和加载等. 另外, 用户还可以方便在项目之间移动数据, 而不会丢失
+        任何历史信息.</para>
 
+      <!--
       <para>The downside of using a single repository is that
         different projects may have different requirements in terms of
         the repository event triggers, such as needing to send commit
@@ -450,6 +458,7 @@
         their project lately, the youngest revision number for the
         repository keeps climbing because other projects are actively
         adding new revisions.<footnote><para>Whether founded in
+            ### TODO
         ignorance or in poorly considered concepts about how to derive
         legitimate software development metrics, global revision
         numbers are a silly thing to fear,
@@ -456,7 +465,16 @@
         and <emphasis>not</emphasis> the kind of thing you should
         weigh when deciding how to arrange your projects and
         repositories.</para></footnote></para>
+      -->
+  <para>缺点是不同的项目对仓库的事件触发的需求可能不同, 例如把提交通知发到不同
+    的邮件列表, 对于如何构成一次合法的提交, 其要求也会有所不同. 当然, 这些问
+    题并非无法克服—只是说所有的钩子脚本都依赖仓库的布局, 而不是假定整个
+    仓库只和单独的一组人有关系. 另外还要注意 Subversion 的版本号是整个仓库范围
+    的, 虽然这些数字并没有任何特殊的魔力, 但还是有人不喜欢看到这样一种情况:
+    虽然他们的项目最近都没有提交什么修改, 但是由于其他项目的活跃, 他们自己的
+    项目的版本号仍然在不断增长.</para>
 
+      <!--
       <para>A middle-ground approach can be taken, too.  For example,
         projects can be grouped by how well they relate to each other.
         You might have a few repositories with a handful of projects
@@ -465,6 +483,11 @@
         added to the repository, at least the developers know that
         those new revisions are at least remotely related to everyone
         who uses that repository.</para>
+      -->
+      <para>还有一种折衷一点的方式可以采用. 比如说根据项目之间的相关性进行
+        分组, 把相关性强的项目放在一个单独的仓库里. 这样的话项目之间共享数
+        据就会更加方便, 如果有新的版本号产生, 开发人员至少会知道这些新的版
+        本号和仓库中的项目都有或多或少的联系.</para>
 
       <para>
         <indexterm>