[svnbook] r5417 committed - branches/1.8/zh/book/ch03-advanced-topics.xml

wuzhouhui at users.sourceforge.net wuzhouhui at users.sourceforge.net
Mon Sep 4 08:11:24 CDT 2017

Revision: 5417
Author:   wuzhouhui
Date:     2017-09-04 13:11:24 +0000 (Mon, 04 Sep 2017)
Log Message:
1.8/zh: translation of chapter 3 in progress

Modified Paths:

Modified: branches/1.8/zh/book/ch03-advanced-topics.xml
--- branches/1.8/zh/book/ch03-advanced-topics.xml	2017-09-03 09:35:49 UTC (rev 5416)
+++ branches/1.8/zh/book/ch03-advanced-topics.xml	2017-09-04 13:11:24 UTC (rev 5417)
@@ -7657,9 +7657,11 @@
+    <!--
     <para>It is commonplace for a developer to find himself working at
       any given time on multiple different, distinct changes to a
       particular bit of source code.  This isn't necessarily due to
+      TODO
       poor planning or some form of digital masochism.  A software
       engineer often spots bugs in his peripheral vision while working
       on some nearby chunk of source code.  Or perhaps he's halfway
@@ -7669,7 +7671,15 @@
       module, safely separated from other changes.  The units might
       overlap, modifying different files in the same module, or even
       modifying different lines in the same file.</para>
+    -->
+    <para>对开发人员来说, 同时在多个不同版本的代码上工作是一件很平常的事情, 这
+      不一定是因为计划有问题, 因为开发人员常常在阅读某一部分的代码时, 发现另
+      一部分代码的问题, 又或许是开发人员把一个大修改拆分成几个逻辑性更强的小
+      修改, 而这几个小修改还没有全部完成. 很多时候, 这些小修改不能完全包含在一
+      个模块里, 修改之间也不能安全地隔开, 修改可能有重叠, 或修改了同一样模块
+      的不同文件, 或修改了同一个文件的不同行.</para>
+    <!--
     <para>Developers can employ various work methodologies
       to keep these logical changes organized.  Some use
       separate working copies of the same repository to hold each
@@ -7682,11 +7692,31 @@
       Each of these methods has its pros and cons, and to a large
       degree, the details of the changes being made heavily influence
       the methodology used to distinguish them.</para>
+    -->
+    <para>开发人员可以采用不同的方法对这些在逻辑上分开的修改进行组织. 有的人
+      使用单独的工作副本保存未完成的修改, 其他人可能会创建短期的特性分支, 还
+      有的人会使用 <command>diff</command> 和 <command>patch</command> 来备份
+      与还原未提交的修改, 每一个修改都对应一个补丁文件. 每一种方法都有各自的
+      优缺点, 而且修改的细节会在很大程度上影响对修改进行区分的方法.</para>
-      </indexterm>Subversion provides a <firstterm>changelists</firstterm>
+      </indexterm>
+      Subversion 提供了一种新方法: <firstterm>修改列表</firstterm> (<firstterm>
+        changelists</firstterm>). 修改列表基本上就是一些应用到工作副本文件上
+      的任意标签 (每个文件上最多只能有一个标签), 用于多个互相关联的文件一起表
+      示目的, 经常使用谷歌软件的用户对此比较熟悉. 比如说 <ulink url=
+        "http://mail.google.com/">谷歌邮箱</ulink> 并没有提供传统的基于文件夹
+      的邮件组织形式, 用户可以把任意的标签应用到邮件上, 如果有多个邮件的标签
+      相同, 就可以说它们是同一个组的, 查看具有类似标签的一组邮件变成了一个简单
+      的用户界面技巧. 很多 Web 2.0 网站也提供了类似的机制, 比如 
+      <ulink url="http://www.youtube.com/">YouTube</ulink> 和
+      <ulink url="http://www.flickr.com/">Flickr</ulink> 的 <quote>标签</quote>
+      (tag), 以及博文的 <quote>类别</quote> (categories). 旧的 <quote>文件与
+        文件夹</quote> 范式对某些应用程序来说过于刻板.</para>
+    <!--
+      Subversion provides a <firstterm>changelists</firstterm>
       feature that adds yet another method to the mix.  Changelists
       are basically arbitrary labels (currently at most one per file)
       applied to working copy files for the express purpose of
@@ -7703,10 +7733,12 @@
       such as <ulink url="http://www.youtube.com/">YouTube</ulink> and
       <ulink url="http://www.flickr.com/">Flickr</ulink>,
       <quote>categories</quote> applied to blog posts, and so on.
+      TODO
       Folks understand today that organization of data is critical,
       but that how that data is organized needs to be a flexible
       concept.  The old files-and-folders paradigm is too rigid for
       some applications.</para>
+    -->
     <para>Subversion's changelist support allows you to create
       changelists by applying labels to files you want to be

More information about the svnbook-dev mailing list