参与社区 ¶

虽然 Subversion 最初由 CollabNet 赞助和托管 (https://www.collab.net/)，但它是一个真正的开源项目，根据 Apache 许可证 2.0 版发布。Subversion 的许多开发者由他们的雇主付费来改进 Subversion，而许多其他人只是优秀的志愿者，他们有兴趣构建更好的版本控制系统。

社区主要通过 IRC、邮件列表和 Subversion 存储库存在。要参与

• 加入我们在 irc.libera.chat 的 #svn-dev 频道（使用 网页界面 或 Matrix 或任何 IRC 软件；存档 在此）。

• 加入 "dev"、"commits" 和 "announce" 邮件列表。dev 列表 ([email protected]) 是几乎所有讨论发生的地方。所有开发问题都应该发到那里，不过你可能想先查看一下列表存档。 "commits" 列表会收到自动提交邮件。有关详细信息，请参阅 https://subversion.org.cn/mailing-lists.html。

• 从 https://svn.apache.org/repos/asf/subversion/trunk/ 获取最新开发源代码的副本。
  新的开发总是发生在 trunk 上。错误修复、增强功能和新功能从那里移植到各个发布分支。

几年来，Subversion 社区每年都会在柏林举行一次黑客马拉松：2016、2015、2014、2013、2012、2011 和 2010 [链接来自 archive.org，一些媒体链接无法使用]。

有很多方法可以加入项目，无论是编写代码，还是测试和/或帮助管理错误数据库。如果你想贡献，请查看

• 错误/问题数据库 https://issues.apache.org/jira/projects/SVN/issues

要提交代码，只需将你的补丁发送到 [email protected]。不，等等，先阅读完本文件，然后开始将补丁发送到 [email protected]。:-)

要帮助管理问题数据库，请查看问题摘要，查找和测试无效或重复其他问题的问题。这两种情况都很常见，前者是因为错误通常在代码中其他更改的副作用中被无意中修复，而后者是因为人们有时会提交问题，而没有注意到它已经被报告过。如果你不确定某个问题，请在 [email protected] 上发布问题。（“Subversion：我们在这里帮助你帮助我们！”）

另一种帮助方法是在某个平台上设置 Subversion 的自动化构建和测试套件运行，并将输出发送到 [email protected] 邮件列表。有关更多详细信息，请参阅 邮件列表页面。

最后，尽管 Subversion 项目的本质是线上的，并且由此产生的用户联系抽象化，但重要的是要意识到，在所有贡献的背后都有真实的人。对待所有其他社区成员就像你希望被对待一样。审查贡献，而不是贡献者；不要惹恼他人，也不要轻易被惹恼。

理论与文档 ¶

1. 设计

   2000 年 6 月编写了一份 设计规范，现在已经过时了。但它仍然很好地介绍了存储库的内部工作原理以及 Subversion 的各个层。

2. API 文档

   有关更多信息，请参阅关于 公共 API 文档 的部分。

3. 增量编辑器

   Karl Fogel 为 O'Reilly 2007 年出版的书籍 Beautiful Code: Leading Programmers Explain How They Think 撰写了一章，涵盖了 Subversion 增量编辑器接口 的设计和使用。

4. 网络协议

   WebDAV 使用 文档介绍了 Subversion 的 DAV 网络协议，它是一种扩展的 HTTP 方言，使用以“http://”或“https://”开头的 URL。

   SVN 协议 文档包含对 Subversion ra_svn 网络协议的正式描述，它是在端口 3690（默认情况下）上的自定义协议，其 URL 以“svn://”或“svn+ssh://”开头。

5. 用户手册

   《版本控制与 Subversion》是一本由 O'Reilly 出版发行的书籍，详细介绍了如何有效地使用 Subversion。本书的文本是免费的，并且正在积极修订。在线版本可在 https://svnbook.subversion.org.cn/ 获取。XML 源代码和其他语言的翻译在 https://sourceforge.net/projects/svnbook/ 的自己的存储库中维护。

6. 系统说明

   系统特定方面的大量设计理念已在 notes/ 目录中的各个文件中记录。

要阅读的代码 ¶

在您贡献代码之前，您需要熟悉现有的代码库和接口。

检出一个 Subversion 的副本（如果您还没有提交访问权限的帐户，则可以匿名检出），这样您就可以查看代码。

在 'subversion/include/' 目录下有很多包含大量文档注释的头文件。如果你仔细阅读这些注释，你将对实现细节有一个很好的理解。以下是一个建议的阅读顺序。

1. 基本构建块： svn_string.h， svn_error.h， svn_types.h

2. svn_io.h， svn_path.h， svn_hash.h， svn_xml.h

3. 关键接口： svn_delta.h

4. 客户端接口： svn_ra.h， svn_wc.h， svn_client.h

5. 仓库和版本化文件系统： svn_repos.h， svn_fs.h

Subversion 试图通过仅使用 C89/C90 语法的 ANSI/ISO C 以及 Apache 可移植运行时 (APR) 库来保持可移植性。APR 是 Apache httpd 服务器使用的可移植性层，更多信息可以在 https://apr.apache.org/ 找到。

由于 Subversion 严重依赖 APR，因此在没有先浏览 APR 中的某些头文件（位于 'apr/include/' 目录下）的情况下，可能难以理解 Subversion。

• 内存池： apr_pools.h

• 文件系统访问： apr_file_io.h

• 哈希表和数组： apr_hash.h， apr_tables.h

Subversion 还试图提供可靠和安全的软件。这只有通过理解 C 编程语言中安全编程的开发人员才能实现。请参阅 'notes/assurance.txt' 以了解这背后的完整理由。具体来说，你应该认真阅读 David Wheeler 的《安全编程》（如 'notes/assurance.txt' 中所述）。如果你在任何时候对更改的安全影响有任何疑问，请在开发者邮件列表中寻求审查。

目录结构 ¶

源代码树的粗略指南

• doc/
  用户和开发者文档。

• tools/
  与 Subversion 协同工作但 Subversion 不依赖的工具。tools/ 中的代码由 Subversion 项目共同维护，并与 Subversion 本身处于相同的开源版权下。

• contrib/
  与 Subversion 协同工作但 Subversion 不依赖的工具，由可能参与或不参与 Subversion 开发的个人维护。contrib/ 中的代码是开源的，但可能与 Subversion 本身具有不同的许可证或版权持有者。

• subversion/
  Subversion 本身的源代码（与外部库相对）。

• subversion/include/
  Subversion 库用户的公共头文件。

• subversion/include/private/
  Subversion 库内部共享的私有头文件。

• subversion/libsvn_fs/
  版本控制“文件系统”API。

• subversion/libsvn_repos/
  围绕 `libsvn_fs` 核心构建的存储库功能。

• subversion/libsvn_delta/
  树增量、文本增量和属性增量的通用代码。

• subversion/libsvn_wc/
  工作副本的通用代码。

• subversion/libsvn_ra/
  存储库访问的通用代码。

• subversion/libsvn_client/
  客户端操作的通用代码。

• subversion/svn/
  命令行客户端。

• subversion/tests/
  自动化测试套件。

分支策略 ¶

Subversion 项目强烈建议在公共主干上进行活跃的开发。对主干的更改具有最高的可见性，并且可以从未发布的代码中获得最大的锻炼。为了使这有利于所有人，我们的主干始终保持稳定。它应该构建。它应该工作。它可能还没有准备好发布，但它肯定应该准备好进行测试。

我们还强烈建议将大型更改分解成几个较小的逻辑提交——每个提交都应满足上述稳定性要求。

也就是说，我们理解将所有这些策略应用于特别大的更改（新功能、全面代码重组等）几乎是不可能的。在这种情况下，您可能需要考虑使用专门用于您的开发任务的自定义分支。以下是一些使您的基于分支的开发工作顺利进行的指南。

This branch exists for the resolution of issue #8810, per the ideas
documented in /trunk/notes/frobnobbing-feature.txt.  It is a feature
branch, receiving regular sync merges from /trunk, and expected to be
reintegrated back thereto.

TODO:

  * compose regression tests        [DONE]
  * add frob identification logic   [STARTED (fitz)]
  * add nobbing bits                []

文档 ¶

  /*** How not to document.  Don't do this. ***/

  /* Make a foo object. */
  static foo_t *
  make_foo_object(arg1, arg2, apr_pool_t *pool)
  {
     /* Create a subpool. */
     apr_pool_t *subpool = svn_pool_create(pool);

     /* Allocate a foo object from the main pool */
     foo_t *foo = apr_palloc(pool, sizeof(*foo));
     ...
  }

      /* Transmit the segment (if its within the scope of our concern). */
      SVN_ERR(maybe_crop_and_send_segment(segment, start_rev, end_rev,
                                          receiver, receiver_baton, subpool));

      /* If we've set CURRENT_REV to SVN_INVALID_REVNUM, we're done
         (and didn't ever reach END_REV).  */
      if (! SVN_IS_VALID_REVNUM(current_rev))
        break;

      /* If there's a gap in the history, we need to report as much
         (if the gap is within the scope of our concern). */
      if (segment->range_start - current_rev < 1)
        {
          svn_location_segment_t *gap_segment;
          gap_segment = apr_pcalloc(subpool, sizeof(*gap_segment));
          gap_segment->range_end = segment->range_start - 1;
          gap_segment->range_start = current_rev + 1;
          gap_segment->path = NULL;
          SVN_ERR(maybe_crop_and_send_segment(gap_segment, start_rev, end_rev,
                                              receiver, receiver_baton,
                                              subpool));
        }

补丁提交指南 ¶

svn checkout https://svn.apache.org/repos/asf/subversion/trunk/ svn-trunk

   Subject: [PATCH] fix for rev printing bug in svn status

   [[[
   Fix issue #1729: Don't crash because of a missing file.

   * subversion/libsvn_ra_ansible/get_editor.c
     (frobnicate_file): Check that file exists before frobnicating.
   ]]]

提交者 ¶

Subversion 项目中的提交者是指那些被授予直接提交更改到我们版本控制资源的权利的人。该项目是精英制的，这意味着（除其他事项外）项目治理由那些做工作的人来处理。提交访问权限有两种类型：完全访问权限和部分访问权限。完全访问权限意味着树中的任何地方，部分访问权限意味着仅限于该提交者特定的专业领域。虽然每个贡献都受到重视，无论其来源如何，但并非每个为 Subversion 贡献代码的人都会获得提交访问权限。

COMMITTERS 文件列出了所有提交者，包括完全提交者和部分提交者，并说明了每个部分提交者的域。

   Approved by: lundblad

   https://svn.haxx.se/dev/archive-2007-11/0848.shtml
   From: Karl Fogel <[email protected]>
   To: [email protected]
   Subject: branch liberalization (was: Elego tree conflicts work)
   Date: Tue, 20 Nov 2007 10:49:38 -0800
   Message-Id: <[email protected]>

------------------------------------------------------------------------
r32135 | stylesen | 2008-07-16 10:04:25 +0200 (Wed, 16 Jul 2008) | 8 lines

Update "check-license.py" so that it can generate license text applicable
to this year.

Obvious fix.

* tools/dev/check-license.py
  (NEW_LICENSE): s/2005/2008/

------------------------------------------------------------------------

发布经理 ¶

发布经理在 Subversion 项目中的作用是处理将代码稳定化、打包并发布给公众的过程。如果我们正在建造飞机，RM 将是检查施工清单、在机身喷涂航空公司标志并向客户交付成品的人。

因此，成为 RM 并没有真正的开发工作。你所需要做的所有工作都是非编码的：协调人员、集中信息，并作为公众声音宣布新的稳定版本。RM 需要执行许多重复性任务，这些任务要么没有自动化，因为还没有人编写工具，要么因为这些任务需要人工验证，这使得自动化变得有些多余。你可以在 制作 Subversion 版本 部分阅读有关发布过程的更多信息。

你可能在此时认为 RM 的职责并不光彩，你有点对了。如果你正在寻找一个能够带来名利地位的项目职位，你最好去实现 trunk 上真正需要完成的东西。如果你正在寻找一些真正帮助那些不关心版本的人专注于代码的东西，那么 RM 非常适合你。

为了鼓励更广泛地传播发布管理知识，RM 角色目前在不同的 受害者 志愿者之间轮换。

补丁经理 ¶

Subversion 通常有一个补丁经理，其工作是监视 dev@ 邮件列表，确保没有补丁“漏网”。

这意味着要监视所有包含“[PATCH]”邮件的线程，并根据线程的进展采取适当的行动。如果线程自行解决（因为补丁已提交，或者因为大家一致认为不需要应用补丁，或者其他原因），则无需采取进一步行动。但如果线程在没有明确决定的情况下消失，则需要将补丁保存在问题跟踪器中。这意味着将任何关于该补丁的讨论线程的摘要以及相关邮件列表存档的链接添加到跟踪器中的某个问题中。对于解决现有问题跟踪器项目的补丁，该补丁将保存到该项目中。否则，将创建一个正确类型的新问题——“DEFECT”、“FEATURE”或“ENHANCEMENT”（不是“PATCH”）——将补丁保存到该新问题中，并将“patch”关键字记录在该问题上。

补丁经理需要对 Subversion 有基本的技术理解，并能够快速浏览线程并大致了解是否达成一致，以及达成何种一致。它不需要实际的 Subversion 开发经验或提交权限。使用邮件阅读软件的专业知识是可选的，但建议 :-）。

当前的补丁管理器是：Gavin 'Beau' Baumanis <[email protected]>。

代码模块化和接口可见性 ¶

Subversion 的代码和头文件根据几个关键点进行隔离：库特定 vs. 库间；公共 vs. 私有。这种分离主要是由于我们对适当的模块化和代码组织的关注，但也因为我们作为广泛采用的公共 API 的提供者和维护者的承诺。当你在 Subversion 中编写新函数时，你需要仔细考虑这些问题，在进行过程中问自己一些问题

“我的新代码的使用者是否局限于单个库中的特定源代码文件？” 如果是这样，你可能想要在同一个源文件中使用一个静态函数。

“我的新函数是否属于该库中的其他源代码需要使用，但库*外部*不需要使用？” 如果是这样，你想要使用一个非静态的、双下划线命名的函数（例如 svn_foo__do_something），并在相应的库特定头文件中包含其原型。

“我的代码需要从不同的库访问吗？” 在这里，你需要回答一些额外的問題，例如“我的代码应该放在我原本要放置它的库中，还是应该放在更通用的实用程序库中，例如 libsvn_subr？” 无论哪种方式，你现在都在考虑使用库间头文件。但在你决定使用哪一个之前，请查看下一个问题...

“我的代码是否具有干净、可维护的 API，可以合理地永久维护，并为 Subversion 公共 API 提供价值？” 如果是这样，你将把原型添加到公共 API 中，直接放在 subversion/include/ 中。如果不是，请仔细检查你的计划——也许你没有选择最佳的方式来抽象你的功能。但有时，库需要共享一些对 Subversion 本身以外的其他软件来说毫无用处的函数。在这种情况下，请使用 subversion/include/private/ 中的私有头文件。

编码风格 ¶

Subversion 使用 ANSI C，并遵循 GNU 编码标准，除了我们不在函数名和其参数列表的左括号之间添加空格。Emacs 用户可以加载 svn-dev.el 来获得正确的缩进行为（这里的大多数源文件会自动加载它，如果 `enable-local-eval` 设置得当）。

阅读 https://www.gnu.org/prep/standards.html 以获取 GNU 编码标准的完整描述。下面是一个简短的示例，展示了最重要的格式指南，包括我们不加空格的函数参数列表括号的例外情况。

   char *                                     /* func type on own line */
   argblarg(char *arg1, int arg2)             /* func name on own line */
   {                                          /* first brace on own line */
     if ((some_very_long_condition && arg2)   /* indent 2 cols */
         || remaining_condition)              /* new line before operator */
       {                                      /* brace on own line, indent 2 */
         arg1 = some_func(arg1, arg2);        /* NO SPACE BEFORE PAREN */
       }                                      /* close brace on own line */
     else
       {
         do                                   /* format do-while like this */
           {
             arg1 = another_func(arg1);
           }
         while (*arg1);
       }
   }

一般来说，即使你确定运算符优先级，也要尽可能使用括号，并愿意添加空格和换行符来避免“代码压缩”。不要太担心垂直密度；使代码可读比在屏幕上多放一行更重要。

使用分页符 ¶

我们在代码和纯文本散文文件中使用分页符（Ctrl-L 字符，ASCII 12）作为节边界。每个节都以一个分页符开头，分页符之后紧跟着节标题。

这有助于使用 Emacs 分页命令的人，例如 `pages-directory` 和 `narrow-to-page`。这样的人并不像你想象的那么少，如果你想成为其中一员，那么在你的 .emacs 中添加 (require 'page-ext)，然后输入 C-x C-p C-h。

错误消息约定 ¶

对于错误消息，以下约定适用

• 只有在需要向 subversion/include/svn_error_codes.h 中找到的一般错误消息添加信息时，才提供特定的错误消息。

• 消息以大写字母开头。

• 尽量使消息少于 70 个字符。

• 不要在错误消息末尾添加句号（“.”）。

• 不要在错误消息中包含换行符。

• 引用信息使用单引号（例如 "'some info'"）。

• 不要在错误消息中包含发生错误的函数名称。如果 Subversion 使用 '--enable-maintainer-mode' 配置标志编译，它会自行提供此信息。

• 在错误字符串中包含路径或文件名时，请确保对它们进行引用（例如 "Can't find '/path/to/repos/userfile'"）。

• 在错误字符串中包含路径或文件名时，请确保在包含之前使用 svn_dirent_local_style() 将它们转换为 规范形式（因为传递到和从 Subversion API 的路径假定为规范形式）。

• 不要使用 Subversion 特定的缩写（例如，使用 "repository" 而不是 "repo"，使用 "working copy" 而不是 "wc"）。

• 如果你想在错误中添加解释，请报告它，然后用冒号和解释，如下所示

         "Invalid " SVN_PROP_EXTERNALS " property on '%s': "
         "target involves '.' or '..'".
       

• 可以在分号后添加建议或其他补充内容，例如

         "Can't write to '%s': object of same name already exists; remove "
         "before retrying".
       

• 请尽量遵守这些约定，避免使用“--”等其他分隔符来分隔错误消息的不同部分。

还可以阅读有关本地化的信息。

APR 池使用约定 ¶

（假设您已经基本了解 APR 池的工作原理；有关详细信息，请参阅 apr_pools.h。）

使用 Subversion 库的应用程序必须在调用任何 Subversion 函数之前调用 apr_initialize()。

Subversion 的一般池使用策略可以概括为两个原则

1. 创建池的调用级别是唯一可以清除或销毁该池的地方。

2. 在无限次迭代时，在进入迭代之前创建一个子池，在循环中使用它，并在每次迭代开始时清除它，然后在循环完成后销毁它，如下所示

            apr_pool_t *iterpool = svn_pool_create(scratch_pool);
   
            for (i = 0; i < n; ++i)
            {
              svn_pool_clear(iterpool);
              do_operation(..., iterpool);
            }
   
            svn_pool_destroy(iterpool);
          

为了支持上述规则，我们使用以下池名称作为约定来表示各种池生命周期

• result_pool：应在其中分配函数输出的池。结果池声明应始终在函数参数列表中找到，而不要在局部块中找到。（但并非所有函数都需要或具有结果池。）

• scratch_pool：应在其中分配所有函数局部数据的池。此池也由调用者提供，调用者可以选择在控制权返回到调用者时立即清除此池。

• iterpool：迭代池，用于循环内部，如上例所示。

（注意：一些旧代码使用单个pool函数参数，该参数充当结果池和临时池。）

通过在循环边界数据中使用迭代池，您可以确保 O(1) 而不是 O(N) 内存泄漏，如果函数从循环内部突然返回（例如，由于错误）。这就是为什么你不应该为在整个函数中持续存在的数据创建子池，而应该使用调用者传入的池。当调用者的池被清除或销毁时，该内存将被回收。如果调用者在循环中调用被调用者，那么相信调用者会在每次迭代时清除池。相同的逻辑一直传播到调用堆栈的顶端。

您使用的池也有助于代码阅读者了解对象生命周期。给定对象仅在循环的一次迭代期间使用，还是需要在循环结束之后持续存在？例如，池选择表明这段代码中发生了很多事情

      apr_hash_t *persistent_objects = apr_hash_make(result_pool);
      apr_pool_t *iterpool = svn_pool_create(scratch_pool);

      for (i = 0; i < n; ++i)
      {
        const char *intermediate_result;
        const char *key, *val;
        
        svn_pool_clear(iterpool);
        SVN_ERR(do_something(&intermediate_result, ..., iterpool));
        SVN_ERR(get_result(intermediate_result, &key, &val, ...,
                           result_pool));
        apr_hash_set(persistent_objects, key, APR_HASH_KEY_STRING, val);
      }

      svn_pool_destroy(iterpool);
      return persistent_objects;

除了某些在完全理解这些原则之前编写的遗留代码之外，Subversion 中几乎所有池的使用都遵循上述准则。

一种这样的遗留模式是在池中分配一个对象，将池存储在对象中，然后释放该池（直接或通过 close_foo() 函数）来销毁对象。

例如

   /*** Example of how NOT to use pools.  Don't be like this. ***/

   static foo_t *
   make_foo_object(arg1, arg2, apr_pool_t *pool)
   {
      apr_pool_t *subpool = svn_pool_create(pool);
      foo_t *foo = apr_palloc(subpool, sizeof(*foo));

      foo->field1 = arg1;
      foo->field2 = arg2;
      foo->pool   = subpool;
   }

   [...]

   [Now some function calls make_foo_object() and returns, passing
   back a new foo object.]

   [...]

   [Now someone, at some random call level, decides that the foo's
   lifetime is over, and calls svn_pool_destroy(foo->pool).]

这很诱人，但它违背了使用池的目的，即不必过多地担心单个分配，而是要关注整体性能和生命周期组。相反，foo_t 通常不应该有 `pool` 字段。只需在当前池中分配您需要的 foo 对象即可——当该池被清除或销毁时，它们将同时消失。

另请参阅 异常处理 部分，了解有关在池被销毁时如何清理与池关联的资源的详细信息。

总结

• 对象不应该拥有自己的池。对象被分配到由构造函数调用者定义的池中。调用者知道对象的生存期，并将通过池来管理它。

• 函数不应该为其操作创建/销毁池；它们应该使用调用者提供的池。同样，调用者更了解函数将如何使用、使用频率、使用次数等，因此它应该负责函数的内存使用。

  例如，考虑一个在紧密循环中多次调用的函数。调用者在每次迭代时清除 scratch 池。因此，创建内部子池是不必要的，并且可能是巨大的开销；相反，函数应该只使用传入的池。

• 每当发生无界迭代时，都应该使用迭代子池。

• 鉴于以上所有内容，将池传递给每个函数几乎是强制性的。由于对象不会为自身记录池，并且调用者始终应该管理内存，因此每个函数都需要一个池，而不是依赖于某些隐藏的魔法池。在有限的情况下，对象可能会记录用于其构造的池，以便它们可以构造子部分，但这些情况应该仔细检查。

另请参阅 跟踪内存泄漏，了解有关诊断池使用问题的提示。

APR 状态码 ¶

始终使用 APR_STATUS_IS_...() 宏来检查 APR 状态码（除了 APR_SUCCESS），而不是通过直接比较。这是为了便携到非 Unix 平台所需的。

异常处理 ¶

好的，以下是如何在 Subversion 中使用异常。

1. 异常存储在 svn_error_t 结构中

   typedef struct svn_error_t
   {
     apr_status_t apr_err;      /* APR error value, possibly SVN_ custom err */
     const char *message;       /* details from producer of error */
     struct svn_error_t *child; /* ptr to the error we "wrap" */
     apr_pool_t *pool;          /* place to generate message strings from */
     const char *file;          /* Only used iff SVN_DEBUG */
     long line;                 /* Only used iff SVN_DEBUG */
   } svn_error_t;
   

2. 如果您是错误的原始创建者，您会执行类似的操作

   return svn_error_create(SVN_ERR_FOO, NULL, 
                           "User not permitted to write file");
       

   注意 NULL 字段... 表示此错误没有子错误，即它是最底层的错误。

   另请参阅关于编写错误消息的部分。

   Subversion 在内部使用 UTF-8 存储其数据。这也适用于“message”字符串。假设 APR 以当前区域设置返回其数据，因此任何由 APR 返回的文本都需要在包含在消息字符串中之前转换为 UTF-8。

3. 如果您收到错误，您有三种选择

   1. 自己处理错误。使用您自己的代码，或者只调用原始的 svn_handle_error(err)。（此例程会展开错误堆栈并打印出消息，将它们从 UTF-8 转换为当前区域设置。）

      当您的例程收到一个它打算忽略或自行处理的错误时，请务必使用 svn_error_clear() 清理它。任何未清除的此类错误都构成内存泄漏。

      返回错误的函数不需要初始化其输出参数。

   2. 向上抛出错误，不作修改

              error = some_routine(foo);
              if (error)
                return svn_error_trace(error);
              

      实际上，更好的方法是使用 SVN_ERR() 宏，它执行相同操作

              SVN_ERR(some_routine(foo));
              

   3. 向上抛出错误，将其包装在一个新的错误结构中，将其作为“child”参数包含在内

              error = some_routine(foo);
              if (error)
                {
                 svn_error_t *wrapper = svn_error_create(SVN_ERR_FOO, error,
                                                         "Authorization failed");
                 return wrapper;
                }
              

      当然，有一个方便的例程可以创建一个包装错误，该错误具有与子错误相同的字段，除了您的自定义消息

              error = some_routine(foo);
              if (error)
                {
                 return svn_error_quick_wrap(error, 
                                             "Authorization failed");
                }
              

      可以使用 SVN_ERR_W() 宏执行相同的操作（也应该这样做）

                SVN_ERR_W(some_routine(foo), "Authorization failed");
              

   在情况 (b) 和 (c) 中，重要的是要知道与池相关的例程分配的资源会在池销毁时自动清理。这意味着在传递错误之前不需要清理这些资源。因此，没有理由不使用 SVN_ERR() 和 SVN_ERR_W() 宏。与池相关的资源是

   • 内存

   • 文件

     所有使用 apr_file_open 打开的文件在池清理时都会关闭。Subversion 在其 svn_io_file_* api 中使用此函数，这意味着使用 svn_io_file_* 或 apr_file_open 打开的文件将在池清理时关闭。

     某些文件（例如锁文件）需要在操作完成后删除。APR 为此目的提供了 APR_DELONCLOSE 标志。以下函数创建在池清理时删除的文件

     • apr_file_open 和 svn_io_file_open（当传递 APR_DELONCLOSE 标志时）

     • svn_io_open_unique_file（当在 delete_on_close 中传递 TRUE 时）

     如果使用 svn_io_file_lock 锁定文件，则会解锁这些文件。

4. 当定义 SVN_ERR__TRACING 时，SVN_ERR() 宏将创建包装错误。这有助于开发人员确定导致错误的原因，并且可以通过 configure 的 --enable-maintainer-mode 选项启用。

5. 有时，您只想返回被调用函数返回的内容，通常是在您自己的函数结束时。避免直接返回结果的诱惑

       /* Don't do this! */
       return some_routine(foo);

   相反，使用 svn_error_trace 元函数返回该值。这确保在启用时堆栈跟踪正确发生。

       return svn_error_trace(some_routine(foo));

安全编码指南 ¶

就像几乎所有其他编程语言一样，C 具有不希望有的特性，这些特性使攻击者能够以可预测的方式使您的程序失败，通常对攻击者有利。这些指南的目的是让您了解 C 的缺陷，这些缺陷适用于 Subversion 项目。鼓励您在审查同行代码时牢记这些缺陷，因为即使是最熟练和偏执的程序员也会偶尔犯错。

输入验证是指定义合法输入并拒绝所有其他输入的行为。代码必须对所有不受信任的输入执行输入验证。

安全边界

Subversion 服务器代码中的安全边界必须被识别为这样，因为这使审计人员能够快速确定边界的质量。安全边界存在于运行代码可以访问用户无法访问的信息的地方，或者代码以高于发出请求的用户的权限运行的地方。此类代码的典型示例是执行访问控制的代码或设置了 SUID 位的应用程序。

对安全边界进行调用的函数必须包含对传递参数的验证检查。自身是安全边界的函数应审核接收到的输入，并在使用不正确的值调用时发出警报。

[### todo: 需要一些来自 Subversion 的示例...]

字符串操作

使用 apr_strings.h 中提供的字符串函数，而不是写入字符串的标准 C 库函数。APR 函数更安全，因为它们会自动进行边界检查和目标分配。虽然在理论上使用普通 C 字符串函数是安全的（例如，当您已经知道源和目标的长度时），但请始终使用 APR 函数，这样代码更不容易出错，更易于审查。

密码存储

帮助用户保护密码安全：当客户端本地读取或写入密码时，应确保文件模式为 0600。如果其他用户可以读取该文件，客户端应退出并显示一条消息，告知用户更改文件模式以防止暴露风险。

堆叠资源的销毁 ¶

某些资源需要销毁才能确保应用程序正常运行。这些资源包括文件，尤其是在 Windows 上无法删除打开的文件。

在编写创建并返回流的 API 时，在后台，该流可能堆叠在文件或其他流上。为了确保正确销毁流所依赖的资源，必须正确调用其所依赖（拥有）的流的析构函数。

最初在 https://svn.haxx.se/dev/archive-2005-12/0487.shtml 中，后来在 https://svn.haxx.se/dev/archive-2005-12/0633.shtml 中，针对文件、流、编辑器和窗口处理程序，对这个问题进行了更一般的讨论。

正如 Greg Hudson 所说

经过考虑，我希望我们能做到以下几点

• 从底层对象读取或写入的流拥有该对象，即关闭流会关闭底层对象（如果适用）。
• 创建流的层（函数或数据类型）负责关闭它，除非上述规则适用。
• 窗口处理程序被认为是一种奇特的流，传递最终的 NULL 窗口被认为是关闭流。

如果你认为 apply_textdelta 是创建窗口处理程序，那么我认为我们并没有偏离太多。svn_stream_from_aprfile 并不拥有其子文件，svn_txdelta_apply 错误地承担了关闭传递给它的窗口流的责任，可能还存在其他偏差。

不过，上述规则有一个例外。当将流作为参数传递给函数时（例如：svn_client_cat2() 的“out”参数），该例程不能调用流的析构函数，因为它没有创建该资源。

如果 svn_client_cat2() 创建了一个流，它也必须调用该流的析构函数。根据上述模型，该流将调用“out”参数的析构函数。然而，这是错误的，因为销毁“out”参数的责任在于其他地方。

为了解决这个问题，至少在流的情况下，引入了 svn_stream_disown()。此函数包装了一个流，确保它不会被销毁，即使任何堆叠在其上的流可能会尝试这样做。

可变参数列表 ¶

当您调用一个接受可变数量参数并期望列表以空指针常量（例如 apr_pstrcat）终止的函数时，不要使用 NULL 符号来终止列表。根据编译器和平台的不同，NULL 可能是一个指针大小的常量，也可能不是；如果不是，该函数可能会最终读取超出参数列表末尾的数据。

相反，请使用 SVN_VA_NULL（从 1.9 版开始在 svn_types.h 中定义），它保证是一个空指针常量。例如

   return apr_pstrcat(cmd->temp_pool, "Cannot parse expression '",
                      arg2, "' in SVNPath: ", expr_err, SVN_VA_NULL);

其他编码约定 ¶

除了 GNU 标准之外，Subversion 还使用以下约定

• 当使用路径或文件名作为大多数 Subversion API 的输入时，请确保使用 svn_dirent_internal_style() API 将它们转换为 Subversion 的内部/规范形式。或者，当从 Subversion API 接收路径或文件名作为输出时，请使用 svn_dirent_local_style() API 将它们转换为平台期望的形式。

• 仅使用空格缩进代码，不要使用制表符。制表符显示宽度没有标准化，而且手动调整使用空格的缩进更容易。

• 将行限制为 79 列，以便代码在最小的标准显示窗口中显示良好。（可能存在例外情况，例如，当声明一个 80 列文本块，其中有几列被缩进、引号等占用时，如果将每一行分成两行会很不合理地混乱。）

• 所有公开的函数、变量和结构体必须用相应的库名标识，例如 libsvn_wc 的 svn_wc_adm_open。所有在库私有头文件（例如 libsvn_wc/wc.h）中声明的库内部声明必须在库前缀后加上两个下划线（例如 svn_wc__ensure_directory）。所有仅对单个文件私有的声明（例如 libsvn_wc/update_editor.c 中的静态函数 get_entry_url）不需要任何额外的命名空间装饰。需要在库外部使用但仍非公开的符号放在 include/private/ 目录下的共享头文件中，并使用双下划线表示法。此类符号只能由 Subversion 核心代码使用。

  回顾

           /* Part of published API: subversion/include/svn_wc.h */
           svn_wc_adm_open()            
           #define SVN_WC_ADM_DIR_NAME ...
           typedef enum svn_wc_schedule_t ...
  
           /* For use within one library only: subversion/libsvn_wc/wc.h */
           svn_wc__ensure_directory()   
           #define SVN_WC__BASE_EXT ... 
           typedef struct svn_wc__compat_notify_baton_t ...
  
           /* For use within one file: subversion/libsvn_wc/update_editor.c */ 
           get_entry_url()
           struct handler_baton {
  
           /* For internal use in svn core code only:
              subversion/include/private/svn_wc_private.h */
           svn_wc__entry_versioned()
        

  在 Subversion 1.5 之前，需要在库外部使用的私有符号被放在公共头文件中，并使用双下划线表示法。这种做法已被放弃，任何此类符号都是遗留的，为了 向后兼容性 而维护。

• 在可能被打印出来（或以其他方式提供给用户）的文本字符串中，只使用前导引号包围路径和其他可引用的内容。例如

           $ svn revert foo
           svn: warning: svn_wc_is_wc_root: 'foo' is not a versioned resource
           $
        

  以前有很多字符串使用反引号作为第一个引号（`foo' 而不是 'foo'），但这在某些字体中看起来很糟糕，而且还会弄乱一些人的自动高亮，因此我们最终决定始终使用前导引号。

• 如果您使用 Emacs，请在您的 .emacs 文件中添加类似以下内容，以便在需要时获得 svn-dev.el 和 svnbook.el

           ;;; Begin Subversion development section
           (defun my-find-file-hook ()
             (let ((svn-tree-path (expand-file-name "~/projects/subversion"))
                   (book-tree-path (expand-file-name "~/projects/svnbook")))
               (cond
                ((string-match svn-tree-path buffer-file-name)
                 (load (concat svn-tree-path "/tools/dev/svn-dev")))
                ((string-match book-tree-path buffer-file-name)
                 ;; Handle load exception for svnbook.el, because it tries to
                 ;; load psgml, and not everyone has that available.
                 (condition-case nil
                     (load (concat book-tree-path "/src/tools/svnbook"))
                   (error
                    (message "(Ignored problem loading svnbook.el.)")))))))
  
           (add-hook 'find-file-hooks 'my-find-file-hook)
           ;;; End Subversion development section
        

  当然，您需要根据您的设置自定义路径。您还可以使正则表达式更具选择性地进行字符串匹配；例如，一位开发者说

        > Here's the regexp I'm using:
        > 
        >     "src/svn/[^/]*/\\(subversion\\|tools\\|build\\)/"
        >
        > Two things to notice there: (1) I sometimes have several
        > working copies checked out under ...src/svn, and I want the
        > regexp to match all of them; (2) I want the hook to catch only
        > in "our" directories within the working copy, so I match
        > "subversion", "tools" and "build" explicitly; I don't want to
        > use GNU style in the APR that's checked out into my repo. :-)
        

• 我们有一个传统，不使用个人作者的姓名标记文件（即，我们不会在源文件顶部特殊位置添加类似“作者：foo”或“@author foo”的代码行）。这样做是为了避免出现领地意识——即使一个文件只有一个作者，我们也希望确保其他人可以自由地进行修改。如果有人似乎对文件拥有个人所有权，其他人可能会不必要地犹豫。

• 在一个句子结束和下一个句子开始之间留两个空格。这有助于提高可读性，并允许人们使用其编辑器的句子移动和操作命令。

• 在整个代码中，还有许多其他不成文的约定，只有在有人无意中不遵守这些约定时才会注意到。只要尽力对做事的方式保持敏感，如有疑问，请咨询。

编写日志消息 ¶

每次提交都需要一条日志消息。

日志消息的目标受众是已经熟悉 Subversion 的开发者，但不一定熟悉这次特定的提交。通常，当有人回过头来阅读更改时，他不再记得所有关于该更改的上下文。即使是他自己提交的更改也是如此！所有讨论、邮件列表线程和其他一切可能都被遗忘；关于更改内容的唯一线索来自日志消息和差异本身。人们也以惊人的频率重新审视更改：例如，可能是几个月后，原始提交已经完成，现在更改正在移植到维护分支。

日志消息是更改的介绍。

• 如果你正在分支上工作，请在你的日志消息前加上

     On the 'name-of-branch' branch: (Start of your log message)
  

• 以一行指示更改的总体性质开始你的日志消息，并在必要时添加描述性段落。

这不仅有助于将开发者置于阅读日志消息其余部分的正确心态，而且还与“ASFBot”机器人配合良好，该机器人将每次提交的第一行回显到实时论坛（如 IRC）。（有关详细信息，请参阅 https://wilderness.apache.org/）

如果提交只是对一个文件进行一个简单的更改，那么你可以省略总体描述，直接进入详细描述，使用下面显示的标准文件名-符号格式。

在整个日志消息中，使用完整的句子，而不是句子片段。片段更容易产生歧义，而写出你的意思只需要几秒钟。某些片段，如“文档修复”、“新文件”或“新函数”是可以接受的，因为它们是标准的习语，所有其他细节都应该出现在源代码中。

日志消息应该列出所有受影响的函数、变量、宏、makefile 目标、语法规则等，包括本次提交中删除的符号的名称。这有助于人们以后在日志中搜索。不要将名称隐藏在通配符中，因为通配符部分可能是以后有人搜索的内容。例如，以下内容不好

   * subversion/libsvn_ra_pigeons/twirl.c
     (twirling_baton_*): Removed these obsolete structures.
     (handle_parser_warning): Pass data directly to callees, instead
      of storing in twirling_baton_*.

   * subversion/libsvn_ra_pigeons/twirl.h: Fix indentation.

以后，当有人试图找出 `twirling_baton_fast` 发生了什么时，如果他们只搜索 “_fast”，可能找不到它。更好的条目应该是

   * subversion/libsvn_ra_pigeons/twirl.c
     (twirling_baton_fast, twirling_baton_slow): Removed these
      obsolete structures. 
     (handle_parser_warning): Pass data directly to callees, instead
      of storing in twirling_baton_*. 

   * subversion/libsvn_ra_pigeons/twirl.h: Fix indentation.

通配符在 `handle_parser_warning` 的描述中是可以的，但只是因为这两个结构在日志条目中的其他地方以全名提及。

你应该在日志消息中包含属性更改。例如，如果你要修改 trunk 上的“svn:ignore”属性，你可以在日志中添加类似以下内容

   * trunk/ (svn:ignore): Ignore 'build'.

以上内容只适用于你维护的属性，不适用于 subversion 维护的属性，如“svn:mergeinfo”。

注意每个文件都有自己的条目，以“*”开头，文件内的更改按符号分组，符号用括号括起来，后面跟着冒号，然后是描述更改的文本。请遵守此格式，即使只更改了一个文件——一致性不仅有助于可读性，还允许软件自动对日志条目进行着色。

作为上述内容的例外，如果你在多个文件中进行了完全相同的更改，请在一个条目中列出所有更改的文件。例如

   * subversion/libsvn_ra_pigeons/twirl.c,
     subversion/libsvn_ra_pigeons/roost.c:
     Include svn_private_config.h.

如果所有更改的文件都在源代码树的深处，你可以通过在更改条目之前记录公共前缀来缩短文件名条目

   [in subversion/bindings/swig/birdsong]

   * dialects/nightingale.c (get_base_pitch): Allow 3/4-tone
     pitch variation to account for trait variability amongst
     isolated populations Erithacus megarhynchos.

   * dialects/gallus_domesticus.c: Remove. Unreliable due to
     extremely low brain-to-body mass ratio.

如果你的更改与问题跟踪器中的特定问题相关，请在日志消息中包含类似“issue #N”的字符串，但请确保你仍然总结了更改的内容。例如，如果一个补丁解决了 issue #1729，那么日志消息可能是

   Fix issue #1729: Don't crash because of a missing file.

   * subversion/libsvn_ra_ansible/get_editor.c
     (frobnicate_file): Check that file exists before frobnicating.

尝试将相关的更改放在一起。例如，如果您创建了 `svn_ra_get_ansible2()`，并弃用了 `svn_ra_get_ansible()`，那么这两个更改应该在日志消息中彼此靠近。

   * subversion/include/svn_ra.h
     (svn_ra_get_ansible2): New prototype, obsoletes svn_ra_get_ansible.
     (svn_ra_get_ansible): Deprecate.

对于大型更改或更改组，将日志条目分组到用空行分隔的段落中。每个段落应该是一组实现单个目标的更改，并且每个组应该以一两句话总结更改开始。当然，真正独立的更改应该在单独的提交中进行。

请参阅 署名，了解如何在提交他人的补丁或提交他们建议的更改时如何给予他人署名。

人们永远不需要通过日志条目来理解当前代码。如果您发现自己要在日志中写下重要的解释，您应该仔细考虑您的文本是否实际上属于注释，并与它解释的代码并排放置。以下是一个正确操作的示例

   (consume_count): If `count' is unreasonable, return 0 and don't
    advance input pointer.

然后，在 `cplus-dem.c` 中的 `consume_count` 中

   while (isdigit((unsigned char)**type))
     {
       count *= 10;
       count += **type - '0';
       /* A sanity check.  Otherwise a symbol like
         `_Utf390_1__1_9223372036854775807__9223372036854775'
         can cause this function to return a negative value.
         In this case we just consume until the end of the string.  */
      if (count > strlen(*type))
        {
          *type = save;
          return 0;
        }

这就是为什么一个新函数，例如，只需要一个日志条目说“新函数”——所有细节都应该在源代码中。

您可以对命名所有更改内容的需求做出常识性的例外。例如，如果您进行了一项更改，该更改需要在程序的其余部分进行微不足道的更改（例如，重命名一个变量），您不必命名所有受影响的函数，您可以简单地说“所有调用者已更改”。重命名任何符号时，请记住提及旧名称和新名称，以便于追踪；请参阅 r861020 以获取示例。

总的来说，在通过搜索标识符来使条目易于查找，以及通过详尽无遗地浪费时间或产生不可读的条目之间存在着矛盾。请使用上述指南和您的最佳判断，并体谅您的同事开发人员。（此外，请使用“svn log”查看其他人是如何编写他们的日志条目的。）

文档或翻译的日志消息有一些比较宽松的指南。命名每个符号的要求显然不适用，如果更改只是在翻译等持续过程中的一次又一次的增量，甚至没有必要命名每个文件。只需简要总结更改，例如：“马达加斯加语翻译的更多工作”。请用英语编写您的日志消息，以便参与项目的所有人都能理解您所做的更改。

如果您正在使用分支来“检查点”您的代码，并且不认为它已准备好进行审查，请在日志消息的顶部，在“在 'xxx' 分支上的通知”之后，添加一些通知，例如

   *** checkpoint commit -- please don't waste your time reviewing it ***

如果该分支上的后续提交需要审查，请在日志消息中提供相应的“svn diff”命令，因为 diff 可能涉及该分支上的两个非相邻提交，审查者不应该花时间弄清楚它们是哪些。

署名 ¶

以一致且可解析的方式记录代码贡献非常重要。这使我们能够编写脚本以找出谁一直在积极贡献——以及他们贡献了什么——这样我们就可以 快速发现潜在的新提交者。Subversion 项目在日志消息中使用人类可读但机器可解析的字段来实现这一点。

提交他人编写的补丁时，在行首使用“Patch by: ”来指示作者

   Fix issue #1729: Don't crash because of a missing file.

   * subversion/libsvn_ra_ansible/get_editor.c
     (frobnicate_file): Check that file exists before frobnicating.

   Patch by: J. Random <[email protected]>

如果多个个人编写了补丁，请将他们分别列在单独的行上——确保每个续行都以空格开头。非提交者应按姓名列出，如果已知，则列出电子邮件。完整和部分提交者应按其来自 COMMITTERS（该文件中最左侧的列）的规范用户名列出。此外，“me”是实际提交更改的人的公认简写。

   Fix issue #1729: Don't crash because of a missing file.

   * subversion/libsvn_ra_ansible/get_editor.c
     (frobnicate_file): Check that file exists before frobnicating.

   Patch by: J. Random <[email protected]>
             Enrico Caruso <[email protected]>
             jcommitter
             me

如果有人发现了错误或指出了问题，但没有编写补丁，请使用“Found by: ” (或“Reported by: ”) 来指示他们的贡献

   Fix issue #1729: Don't crash because of a missing file.

   * subversion/libsvn_ra_ansible/get_editor.c
     (frobnicate_file): Check that file exists before frobnicating.

   Found by: J. Random <[email protected]>

如果有人提出了有用的建议，但没有编写补丁，请使用“Suggested by: ” 来指示他们的贡献

   Extend the Contribulyzer syntax to distinguish finds from ideas.

   * www/hacking.html (crediting): Adjust accordingly.

   Suggested by: dlr

如果有人试用了一个补丁，请使用“Tested by: ”

    Fix issue #23: random crashes on FreeBSD 3.14.
    
    Tested by: Old Platformer
    (I couldn't reproduce the problem, but Old hasn't seen any crashes since
    he applied the patch.)
    
    * subversion/libsvn_fs_sieve/obliterate.c
      (cover_up): Account for sieve(2) returning 6.

如果有人审查了更改，请使用“Review by: ” (或“Reviewed by: ” 如果你更喜欢)

   Fix issue #1729: Don't crash because of a missing file.

   * subversion/libsvn_ra_ansible/get_editor.c
     (frobnicate_file): Check that file exists before frobnicating.

   Review by: Eagle Eyes <[email protected]>

一个字段可以有多行，一个日志消息可以包含任何组合的字段

   Fix issue #1729: Don't crash because of a missing file.

   * subversion/libsvn_ra_ansible/get_editor.c
     (frobnicate_file): Check that file exists before frobnicating.

   Patch by: J. Random <[email protected]>
             Enrico Caruso <[email protected]>
             me
   Found by: J. Random <[email protected]>
   Review by: Eagle Eyes <[email protected]>
              jcommitter

有关贡献的更多详细信息应列在相应字段后面的括号内。这种旁注始终适用于上面的字段；在以下示例中，字段已为可读性而隔开，但请注意，间距是可选的，对于可解析性来说不是必需的

   Fix issue #1729: Don't crash because of a missing file.

   * subversion/libsvn_ra_ansible/get_editor.c
     (frobnicate_file): Check that file exists before frobnicating.

   Patch by: J. Random <[email protected]>
   (Tweaked by me.)

   Review by: Eagle Eyes <[email protected]>
              jcommitter
   (Eagle Eyes caught an off-by-one-error in the basename extraction.)

目前，这些字段

   Patch by:
   Suggested by:
   Found by:
   Review by:
   Tested by:

是唯一正式支持的署名字段（其中“支持”意味着脚本知道要查找它们），并且它们在 Subversion 日志消息中被广泛使用。未来的字段可能采用“VERB by: ”的形式，有时有人可能会使用听起来很正式但实际上并非如此的字段——例如，有一些“Inspired by: ”的实例。这些是可以的，但尽量使用正式字段或括号内的旁注，而不是创建自己的字段。此外，当报告者已在问题中记录时，不要使用“Reported by: ”；相反，只需引用该问题即可。

查看 Subversion 的现有日志消息以了解如何在实践中使用这些字段。来自您的 trunk 工作副本顶部的此命令将有所帮助

svn log | contrib/client-side/search-svnlog.pl "(Patch|Review|Suggested) by: "

注意：在一些提交消息中看到的“Approved by: ”字段与这些署名字段完全无关，通常不会被脚本解析。它只是指示谁批准了部分提交者在其通常区域之外的提交，或者（在合并到发布分支的情况下）谁投票赞成将更改合并的标准语法。

GitHub ¶

Subversion 代码库镜像到 GitHub 上：https://github.com/apache/subversion/.

一些用户可能会在 GitHub 上创建 Pull Request。如果代码提交到 Subversion 代码库，请确保在日志消息中包含文本以自动关闭 Pull Request。

This fixes #NNN in GitHub

要管理 Pull Request 而不提交代码，您必须拥有与您的 ASF ID 关联的 GitHub 帐户，并且必须由 ASF Infra 为您的帐户分配 triager 角色。

Unix 下的配置/构建系统 ¶

Greg Stein 为 Subversion 编写了一个自定义构建系统，该系统之前一直使用 `automake` 和递归 Makefile。现在它使用单个顶级 Makefile，该文件从 Makefile.in（在版本控制下）生成。`Makefile.in` 反过来包含 `build-outputs.mk`，该文件由 `gen-make.py` 脚本从 `build.conf` 自动生成。因此，后两者在版本控制下，但 `build-outputs.mk` 则不在。

以下是 Greg 描述该系统的原始邮件，以及一些关于修改它的建议

   From: Greg Stein <[email protected]>
   Subject:  new build system (was: Re: CVS update: MODIFIED: ac-helpers ...)
   To: [email protected]
   Date: Thu, 24 May 2001 07:20:55 -0700
   Message-ID: <[email protected]>

   On Thu, May 24, 2001 at 01:40:17PM -0000, [email protected] wrote:
   >   User: gstein
   >   Date: 01/05/24 06:40:17
   >
   >   Modified:    ac-helpers .cvsignore svn-apache.m4
   >   Added:       .        Makefile.in
   >   Log:
   >   Switch over to the new non-recursive build system.
   >...

   Okay... this is it. We're now on the build system.

       "It works on my machine."

   I suspect there may be some tweaks to make on different OSs. I'd be
   interested to hear if Ben can really build with normal BSD make. It
   should be possible.

   The code supports building, installation, checking, and
   dependencies. It does *NOT* yet deal with the doc/ subdirectory. That
   is next; I figured this could be rolled out and get the kinks worked
   out while I do the doc/ stuff.  Oh, it doesn't build Neon or APR yet
   either. I also saw a problem where libsvn_fs wasn't getting built
   before linking one of the test proggies (see below).

   Basic operation: same as before.

   $ ./autogen.sh
   $ ./configure OPTIONS
   $ make
   $ make check
   $ make install

   There are some "make check" scripts that need to be fixed up. That'll
   happen RSN. Some of them create their own log, rather than spewing to
   stdout (where the top-level make will place the output into
   [TOP]/tests.log).

   The old Makefile.am files are still around, but I'll be tossing those
   along with a bunch of tweaks to all the .cvsignore files. There are a
   few other cleanups, too. But that can happen as a step two.

   [ $ cvs rm -f `find . -name Makefile.rm`

     See the mistake in that line? I didn't when I typed it. The find
     returned nothing, so cvs rm -f proceeded to delete my entire
     tree. And the -f made sure to delete all my source files, too. Good
     fugging thing that I had my mods in some Emacs buffers, or I'd be
     bitching.

     I am *so* glad that Ben coded SVN to *not* delete locally modified
     files *and* that we have an "undel" command. I had to go and tweak a
     bazillion Entries files to undo the delete...
   ]

   The top-level make has a number of shortcuts in it (well, actually in
   build-outputs.mk):

   $ make subversion/libsvn_fs/libsvn_fs.la

   or

   $ make libsvn_fs

   The two are the same. So... when your test proggie fails to link
   because libsvn_fs isn't around, just run "make libsvn_fs" to build it
   immediately, then go back to the regular "make".

   Note that the system still conditionally builds the FS stuff based
   on whether DB (See 'Building on Unix' below) is available, and
   mod_dav_svn if Apache is available.

   Handy hint: if you don't like dependencies, then you can do:

   $ ./autogen.sh -s

   That will skip the dependency generation that goes into
   build-outputs.mk. It makes the script run quite a bit faster (48 secs
   vs 2 secs on my poor little Pentium 120).

   Note that if you change build.conf, you can simply run:

   $ ./gen-make.py build.conf

   to regen build-outputs.mk. You don't have to go back through the whole
   autogen.sh / configure process.

   You should also note that autogen.sh and configure run much faster now
   that we don't have the automake crap. Oh, and our makefiles never
   re-run configure on you out of the blue (gawd, I hated when automake
   did that to me).

   Obviously, there are going to be some tweaky things going on. I also
   think that the "shadow" builds or whatever they're called (different
   source and build dirs) are totally broken. Something tweaky will have
   to happen there.  But, thankfully, we only have one Makefile to deal
   with.

   Note that I arrange things so that we have one generated file
   (build-outputs.mk), and one autoconf-generated file (Makefile from
   .in).  I also tried to shove as much logic/rules into
   Makefile.in. Keeping build-outputs.mk devoid of rules (thus, implying
   gen-make.py devoid of rules in its output generation) manes that
   tweaking rules in Makefile.in is much more approachable to people.

   I think that is about it. Send problems to the dev@ list and/or feel
   free to dig in and fix them yourself. My next steps are mostly
   cleanup. After that, I'm going to toss out our use of libtool and rely
   on APR's libtool setup (no need for us to replicate what APR already
   did).

   Cheers,
   -g

   --
   Greg Stein, http://www.lyra.org/

以下是一些针对更改或测试配置/构建系统的建议

   From: Karl Fogel <[email protected]>
   To: [email protected]
   Subject: when changing build/config stuff, always do this first
   Date: Wed 28 Nov 2001

   Yo everyone: if you change part of the configuration/build system,
   please make sure to clean out any old installed Subversion libs
   *before* you try building with your changes.  If you don't do this,
   your changes may appear to work fine, when in fact they would fail if
   run on a truly pristine system.

   This script demonstrates what I mean by "clean out".  This is
   `/usr/local/cleanup.sh' on my system.  It cleans out the Subversion
   libs (and the installed httpd-2.0 libs, since I'm often reinstalling
   that too):

      #!/bin/sh

      # Take care of libs
      cd /usr/local/lib || exit 1
      rm -f APRVARS
      rm -f libapr*
      rm -f libexpat*
      rm -f libneon*
      rm -f libsvn*

      # Take care of headers
      cd /usr/local/include || exit 1
      rm -f apr*
      rm -f svn*
      rm -f neon/*

      # Take care of headers
      cd /usr/local/apache2/lib || exit 1
      rm -f *

   When someone reports a configuration bug and you're trying to
   reproduce it, run this first. :-)

   The voice of experience,
   -Karl

自动化测试 ¶

有关如何使用和将测试添加到 Subversion 自动化测试框架的说明，请阅读 subversion/tests/README 和 subversion/tests/cmdline/README。

构建农场 ¶

The ASF 基础设施 团队管理着一个 BuildBot 构建/测试农场。Subversion 项目的 BuildBot 水平线位于此处

• 生产构建
• 回溯和 RAT 状态
• 兼容性测试
• 整个农场

有关构建服务的更多信息，请访问 ci2.apache.org。

如果您想接收有关 buildbot 构建和测试失败的通知，请订阅 notifications@ 邮件列表。

Buildbot 在 Infra 存储库 中配置，具体来说，是 subversion.py 文件。

在代码之前编写测试用例 ¶

From: Karl Fogel <[email protected]>
Subject: writing test cases
To: [email protected]
Date: Mon, 5 Mar 2001 15:58:46 -0600

Many of us implementing the filesystem interface have now gotten into
the habit of writing the test cases (see fs-test.c) *before* writing
the actual code.  It's really helping us out a lot -- for one thing,
it forces one to define the task precisely in advance, and also it
speedily reveals the bugs in one's first try (and second, and
third...).

I'd like to recommend this practice to everyone.  If you're
implementing an interface, or adding an entirely new feature, or even
just fixing a bug, a test for it is a good idea.  And if you're going
to write the test anyway, you might as well write it first. :-)

Yoshiki Hayashi's been sending test cases with all his patches lately,
which is what inspired me to write this mail to encourage everyone to
do the same.  Having those test cases makes patches easier to examine,
because they show the patch's purpose very clearly.  It's like having
a second log message, one whose accuracy is verified at run-time.

That said, I don't think we want a rigid policy about this, at least
not yet.  If you encounter a bug somewhere in the code, but you only
have time to write a patch with no test case, that's okay -- having
the patch is still useful; someone else can write the test case.

As Subversion gets more complex, though, the automated test suite gets
more crucial, so let's all get in the habit of using it early.

-K

使用 SVN_DBG 调试 ¶

SVN_DBG 调试工具是一个 C 预处理器宏，它将调试输出发送到 stdout（默认）或 stderr，同时不干扰 SVN 测试套件。

它提供了一种替代调试器（如 gdb）的方案，或者提供额外的信息来帮助使用调试器。它可能在无法使用调试器的场景中特别有用。

svn_debug 模块包含两个调试辅助宏，它们将调用文件的行号和类似 printf 的参数打印到 #SVN_DBG_OUTPUT stdio 流（默认情况下为 #stdout）

SVN_DBG( ( const char *fmt, ...) ) /* double braces are neccessary */

SVN_DBG_PROPS( ( apr_hash_t *props, const char *header_fmt, ...) )

控制 SVN_DBG 输出

• 当 svn 配置了 --enable-maintainer-mode 时，SVN_DBG 会被启用。
• SVN 测试套件会自动关闭 SVN_DBG 输出，要手动抑制输出，请在 shell 环境中将 SVN_DBG_QUIET 变量设置为 1。
• 完成后，请确保从您提交的任何代码以及您发送到列表的任何补丁中删除任何 SVN_DBG 和 SVN_DBG_PROPS 宏的实例。（即：不要忘记在病人身上留下手术刀！）

SVN_DBG 宏定义和代码位于

• subversion/include/private/svn_debug.h
• subversion/libsvn_subr/debug.c

显示 SVN_DBG 宏使用示例的补丁

Index: subversion/libsvn_fs_fs/fs_fs.c
===================================================================
--- subversion/libsvn_fs_fs/fs_fs.c     (revision 1476635)
+++ subversion/libsvn_fs_fs/fs_fs.c     (working copy)
@@ -2303,6 +2303,9 @@ get_node_revision_body(node_revision_t **noderev_p
 
   /* First, try a cache lookup. If that succeeds, we are done here. */
   SVN_ERR(get_cached_node_revision_body(noderev_p, fs, id, &is_cached, pool));
+  SVN_DBG(("Getting %s from: %s\n", 
+           svn_fs_fs__id_unparse(id),
+           is_cached ? "cache" : "disk"));
   if (is_cached)
     return SVN_NO_ERROR;

显示 SVN_DBG_PROPS 宏使用示例的补丁

Index: subversion/svn/proplist-cmd.c
===================================================================
--- subversion/svn/proplist-cmd.c	(revision 1475745)
+++ subversion/svn/proplist-cmd.c	(working copy)
@@ -221,6 +221,7 @@ svn_cl__proplist(apr_getopt_t *os,
                                       URL, &(opt_state->start_revision),
                                       &rev, ctx, scratch_pool));
+      /*  this can be called with svn proplist  --revprop -r <rev> */
+      SVN_DBG_PROPS((proplist,"The variable apr_hash_t *proplist contains: "));
       if (opt_state->xml)
         {
           svn_stringbuf_t *sb = NULL;

调试服务器 ¶

   % gdb httpd
   (gdb) run -X
   ^C
   (gdb) break some_func_in_mod_dav_svn
   (gdb) continue

   /usr/local/apache2/logs/error_log
   /usr/local/apache2/logs/access_log

  svn: Malformed network data
  svn: Connection closed unexpectedly

  % gdb svn
  (gdb) break marshal.c:NNN
  (gdb) run ARGS
  Breakpoint 1, vparse_tuple (list=___, pool=___, fmt=___, 
    ap=___) at subversion/libsvn_ra_svn/marshal.c:NNN
  NNN                                 "Malformed network data");

  % gdb svnserve
  (gdb) break marshal.c:NNN
  (gdb) run -X

跟踪网络流量 ¶

跟踪客户端和服务器之间的网络流量有助于调试。有几种方法可以进行网络跟踪（此列表并不详尽）。

在进行网络跟踪时，您可能需要禁用压缩 - 请参阅 servers 配置文件中的 http-compression 参数。

svn ls http://example.com/svn/repos/trunk \
    --config-option servers:global:http-proxy-host=localhost \
    --config-option servers:global:http-proxy-port=9630 \
    --config-option servers:global:http-compression=no

追踪内存泄漏 ¶

我们使用 APR 池，这使得我们在严格意义上很少出现内存泄漏；我们分配的所有内存最终都会被清理。但有时操作会占用比预期更多的内存；例如，检出大型源代码树不应该比检出小型源代码树占用更多内存。当这种情况发生时，通常意味着我们正在从生命周期过长的池中分配内存。

如果您有喜欢的内存泄漏跟踪工具，您可以使用 --enable-pool-debug 配置（这将使每个池分配使用它自己的 malloc()），安排在操作中间退出，然后转到它。如果没有，这里还有另一种方法

• 使用 --enable-pool-debug=verbose-alloc 配置。确保重新构建所有 APR 和 Subversion，以便每个分配都获得文件和行信息。

• 运行操作，将 stderr 管道到文件。希望您有充足的磁盘空间。

• 在文件中，您将看到许多类似于以下内容的行

      POOL DEBUG: [5383/1024] PCALLOC (      2763/      2763/      5419) \
      0x08102D48 "subversion/svn/main.c:612"                             \
      <subversion/libsvn_subr/auth.c:122> (118/118/0)
     

  您最关心的是第十个字段（带引号的字段），它为您提供了创建此分配的池的文件和行号。转到该文件和行，并确定池的生存期。在上面的示例中，main.c:612 表示此分配是在 svn 客户端的顶级池中进行的。如果这是一个在操作过程中多次重复的分配，则表明存在内存泄漏的来源。第十一个字段（带括号的字段）提供了分配本身的文件和行号。

邮件列表 ¶

• 发布地点
• 发布时机
• 格式
• 回复
• 发送补丁
• 语言和编码

以下建议基于多年 Subversion 邮件列表的经验，并针对这些列表中最常遇到的问题。它不应被视为邮件列表礼仪的完整指南——如果你需要，可以在网上轻松找到其中之一。

如果你在发帖到我们的邮件列表时遵循这些约定，你的帖子更有可能被阅读和回复。

   Blue asparagus
     |
     |_ Re: Blue asparagus
         |
         |_ Yellow elephants (was: Re: Blue asparagus)    <-- ### switch ###
            |
            |_ Re: Yellow elephants

错误/问题 ¶

• 如何报告错误
• 在哪里报告错误
• 里程碑管理
• 问题分类
• 安全

Subversion 不是完美的软件。它包含错误，缺少功能，并且像任何其他软件一样有改进的空间。与大多数软件项目一样，Subversion 项目使用问题跟踪工具来管理软件中已知的未解决问题。但也许与大多数软件项目不同的是，我们试图让我们的问题跟踪器相对没有杂物。这并不是说我们不想听到关于 Subversion 问题的信息——毕竟，我们无法修复我们不知道的问题。只是我们发现管理不善的问题跟踪器弊大于利。

这封邮件几乎说明了一切（除了现在您应该在发布到 dev@ 列表之前发布到 users@ 列表）。

   From: Karl Fogel <[email protected]>
   Subject: Please ask on the list before filing a new issue.
   To: [email protected]
   Date: Tue, 30 Jul 2002 10:51:24 (CDT)
   
   Folks, we're getting tons of new issues, which is a Good Thing in
   general, but some of them don't really belong in the issue tracker.
   They're things that would be better solved by a quick conversation
   here on the dev list.  Compilation problems, behavior questions,
   feature ideas that have been discussed before, that sort of thing.
   
   *Please* be more conservative about filing issues.  The issues
   database is physically much more cumbersome than email.  It wastes
   people's time to have conversations in the issues database that should
   be had in email.  (This is not a libel against the issue tracker, it's
   just a result of the fact that the issues database is for permanent
   storage and flow annotation, not for real-time conversation.)
   
   If you encounter a situation where Subversion is clearly behaving
   wrongly, or behaving opposite to what the documentation says, then
   it's okay to file the issue right away (after searching to make sure
   it isn't already filed, of course!).  But if you're
   
      a) Requesting a new feature, or
      b) Having build problems, or
      c) Not sure what the behavior should be, or
      d) Disagreeing with current intended behavior, or
      e) Not TOTALLY sure that others would agree this is a bug, or
      f) For any reason at all not sure this should be filed,
   
   ...then please post to the dev list first.  You'll get a faster
   response, and others won't be forced to use the issues database to
   have the initial real-time conversations.
   
   Nothing is lost this way.  If we eventually conclude that it should be
   in the issue tracker, then we can still file it later, after the
   description and reproduction recipe have been honed on the dev list.
   
   Thank you,
   -Karl

以下是我们要求人们在报告 Subversion 问题或请求增强功能时遵守的政策。

    for i in issues_marked_as("---"):
      if issue_is_a_dup_of_some_other_issue(i):
        close_as_dup(i)
      elif issue_is_invalid(i):
        # A frequent reason for invalidity is that the reporter
        # did not follow the "buddy system" for filing.
        close_as_invalid(i)
      elif issue_already_fixed(i):
        version = fixed_in_release(i)
        move_to_milestone(i, version)
        close_as_fixed(i)
      elif issue_unreproducible(i):
        close_as_worksforme(i)
      elif issue_is_real_but_we_won't_fix_it(i):
        close_as_wontfix(i)
      elif issue_is_closeable_for_some_other_reason(i):
        close_it_for_that_reason(i)

      # Else issue should remain open, so DTRT with it...

      # Set priority, environment, component, etc, as needed.
      adjust_all_fields_that_need_adjustment(i)

      # Figure out where to put it.
      if issue_is_a_lovely_fantasy(i):
        move_to_milestone(i, "blue-sky")
      if issue_is_not_important_enough_to_block_any_particular_release(i):
        move_to_milestone(i, "nonblocking")
      elif issue_resolution_would_require_incompatible_changes(i):
        move_to_milestone(i, "2.0-consider")
      elif issue_hurts_people_somewhat(i):
        move_to_milestone(i, "1.6-consider")  # or whatever
      elif issue_hurts_people_a_lot(i):
        move_to_milestone(i, "1.5-consider")
      elif issue_hurts_and_hurts_and_should_block_the_release(i):
        move_to_milestone(i, "1.5")

发布 Subversion 版本 ¶

• Subversion 版本发布流程
• 版本号
• 版本间兼容性
• 自定义版本
• 弃用
• 稳定和维护版本
• 创建 Subversion 版本
• 通知翻译人员
• 准备发布版本
• 发布版本
• 签署源代码分发包（又称 tarball）
• 实际发布
• 创建和维护发布分支
• 准备创建新的次要版本分支
• 创建新的次要版本分支
• 将更改移植到发布分支
• 管理 CHANGES 文件
• 编写分支的初始内容
• 为补丁版本添加内容
• 如何 *不* 制作 Subversion 版本

本文档通常可以分为三个部分，按具体程度递增

• 高级发布计划和策略，例如版本号和兼容性。这回答了诸如“何时创建压缩包？”和“压缩包的内容应该是什么？”之类的问题。
• 创建版本时要采取的步骤。本节解决“如何管理版本？”的问题。
• 如何构建一组发行版压缩包。本节讨论从存储库中的源代码到一组具有所需内容的可分发 .tar.gz 或 .zip 文件所需的步骤。

Subversion 发行版管理员使用一组在名为 release.py 的 Python 脚本中编写的步骤。此脚本可用于执行发行流程中的大多数自动化步骤。使用 -h 选项运行它以获取更多信息。

除了以下项目特定指南外，有志于成为发行版管理员的人可能还想阅读有关一般 Apache 发行策略 的信息。它们有时看起来有点拼凑，但能很好地说明一般最佳实践以及 Subversion 如何融入更大的 ASF 生态系统。

   1.0.1  -->  first stable patch release of 1.0
   1.1.0  -->  next stable minor release of 1.x after 1.0.x
   1.1.1  -->  first stable patch release of 1.1.x
   1.1.2  -->  second stable patch release of 1.1.x
   1.2.0  -->  next stable minor release after that

   version 1.7.1-dev (under development)

   /**
    * Similar to svn_repos_dump_fs3(), but with a @a feedback_stream instead of
    * handling feedback via the @a notify_func handler
    *
    * @since New in 1.1.
    * @deprecated Provided for backward compatibility with the 1.6 API.
    */
   SVN_DEPRECATED
   svn_error_t *
   svn_repos_dump_fs2(svn_repos_t *repos,
                      svn_stream_t *dumpstream,
                      svn_stream_t *feedback_stream,
                      svn_revnum_t start_rev,
                      svn_revnum_t end_rev,
                      svn_boolean_t incremental,
                      svn_boolean_t use_deltas,
                      svn_cancel_func_t cancel_func,
                      void *cancel_baton,
                      apr_pool_t *pool);

   * r98765 (issue #56789)
     Make commit editor take a closure object for future mindreading.
     Justification:
       API stability, as prep for future enhancement.
     Branch: 1.8.x-r98765
     Notes:
       There was consensus on the desirability of this feature in
       the near future; see thread at http://... (Message-Id: blahblah).
       Merge with --accept=mc.
     Concerns:
       Vetoed by jerenkrantz due to privacy concerns with the
       implementation; see thread at http://... (Message-Id: blahblah)
     Votes:
       +1: ghudson, bliss
       +0: cmpilato
       -0: gstein
       -1: jerenkrantz

 * r31833
   svndumpfilter: Don't match prefixes to partial path components.
   Fixes #desc4 of issue #1853.
   Votes:
     +1: danielsh, hwright
     +1 (non-binding): stylesen

   * r30643, r30653, r30785
     Update bash completion script.
     Votes:
       +1: arfrever (r30785 only), stylesen

sed -e '/^ *Translat.*:$/,/:$/!d' -e 's/^ *[^ ]* *\([^>]*>\).*/\1/;t;d' COMMITTERS

./tools/po/l10n-report.py

mkdir -p /opt/svnrm && cd /opt/svnrm && $SVN_SRC_DIR/tools/dist/release.py build-env X.Y.Z

./release.py roll X.Y.Z 1234

    a) tar zxvf subversion-X.Y.Z.tar.gz;  cd subversion-X.Y.Z
    b) ./configure
 
       See INSTALL, section III.B for detailed instructions on
       configuring/building Subversion.
 
       If you installed Apache in some place other than the default, as
       mentioned above, you will need to use the same
       --prefix=/usr/local/apache2 option as used to configure Apache.
 
       You may also want to use --enable-mod-activation, which will
       automatically enable the required Subversion modules in the
       Apache config file.
 
    c) make
    d) make check
    e) make install (this activates mod_dav)
    f) make davcheck
 
       For this, start up Apache after having configured according to
       the directions in subversion/tests/cmdline/README.
 
       Make sure, that if you maintain a development installation of
       apache, that you check the config file and update it for the
       new release area where you're testing the tar-ball.
 
       (Unless you rename the tree which gets extracted from the
       tarball to match what's in httpd.conf, you will need to edit
       httpd.conf)
 
    g) make svncheck
 
       First, start up svnserve with these args:
 
          $ subversion/svnserve/svnserve -d -r \
            `pwd`/subversion/tests/cmdline
 
       -d tells svnserve to run as a daemon
       -r tells svnserve to use the following directory as the
          logical file system root directory.
 
       After svnserve is running as a daemon 'make svncheck' should run
 
    h) Then test that you can check out the Subversion repository
       with this environment:
 
          subversion/svn/svn co https://svn.apache.org/repos/asf/subversion/trunk
 
    i) Verify that the perl, python, and ruby swig bindings at least compile.
       If you can't do this, then have another developer verify.
 
       (see bindings/swig/INSTALL for details)
 
       Ensure that ./configure detected a suitable version of swig,
       perl, python, and ruby.  Then:
 
          make swig-py
          make check-swig-py
          sudo make install-swig-py
 
          make swig-pl
          make check-swig-pl
          sudo make install-swig-pl
 
          make swig-rb
          make check-swig-rb
          sudo make install-swig-rb

    j) Verify that the javahl bindings at least compile.
       If you can't do this, then have another developer verify.
 
       (see subversion/bindings/javahl/README for details)
 
       Ensure that ./configure detected a suitable jdk, and then
       possibly re-run with '--enable-javahl', '--with-jdk=' and
       '--with-junit=':
 
          make javahl
          sudo make install-javahl
          make check-javahl

    k) Verify that the ctypes python bindings at least compile.
       If you can't do this then have another developer verify.

       (see subversion/bindings/ctypes-python/README for details)

       Ensure that ./configure detected a suitable ctypesgen, and
       then possibly re-run with '--with-ctypesgen':

          make ctypes-python
          sudo make install-ctypes-python
          make check-ctypes-python 

    l) Verify that get-deps.sh works and does not emit any errors.

          ./get-deps.sh

    release.py sign-candidates X.Y.Z

    gpg -ba subversion-X.Y.Z.tar.bz2
    gpg -ba subversion-X.Y.Z.tar.gz
    gpg -ba subversion-X.Y.Z.zip

    release.py create-tag X.Y.Z 1234

release.py post-candidates 1.7.0

    release.py get-keys
    release.py --target /path/to/dist/dev/subversion/wc check-sigs 1.7.0-rc4

    gpg -ba -o - subversion-1.7.0-rc4.tar.bz2 >> subversion-1.7.0-rc4.tar.bz2.asc

 release.py --target /path/to/dist/dev/subversion/wc sign-candidates 1.7.0-rc4

    bzip2 -cd subversion-1.7.0-rc4.tar.bz2 \
    | gzip -9n > subversion-1.7.0-rc4.tar.gz

release.py move-to-dist 1.7.0

release.py clean-dist

curl -u USERNAME "https://reporter.apache.org/addrelease.py?date=`date +%s`&committee=subversion&version=VERSION&xdate=`date +%F`"

release.py --verbose create-release-branch A.B.0

release.py --verbose write-release-notes A.B.0 > .../docs/release-notes/A.B.html
svn add .../docs/release-notes/A.B.html
svn ci -m "Add release notes template." .../docs/release-notes/A.B.html

svn checkout --depth=empty https://svn-master.apache.org/repos/asf/subversion/branches ~svnsvn/src/svn
svn up ~svnsvn/src/svn/A.B.x  # for each supported branch

sudo -H -u svnsvn  svn up ~svnsvn/src/svn/A.B.x

sudo -H -u svnsvn  svn up -r0 ~svnsvn/src/svn/Z.Z.x

release.py write-changelog

本地化 (l10n) ¶

• 本地化概述
• 软件版本要求
• 开始新的翻译
• 验证您的 po 文件
• 提交您的 po 文件
• 更新现有的 po 文件
• 分支维护
• po 和 mo 文件的要求
• 空字符串 msgid 部分的约定
• 翻译团队
• 单引号与双引号
• 错误消息约定

翻译被分为两个领域。首先，是翻译发送给连接客户端的服务器消息。这个问题目前已被搁置。其次是翻译客户端及其库。

   #include "svn_private_config.h"

  # SOME DESCRIPTIVE TITLE.
  # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
  # This file is distributed under the same license as the PACKAGE package.
  # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.

  # <Your language> translation for subversion package
  #    Licensed to the Apache Software Foundation (ASF) under one
  #    or more contributor license agreements.  See the NOTICE file
  #    distributed with this work for additional information
  #    regarding copyright ownership.  The ASF licenses this file
  #    to you under the Apache License, Version 2.0 (the
  #    "License"); you may not use this file except in compliance
  #    with the License.  You may obtain a copy of the License at
  #
  #      http://www.apache.org/licenses/LICENSE-2.0
  #
  #    Unless required by applicable law or agreed to in writing,
  #    software distributed under the License is distributed on an
  #    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  #    KIND, either express or implied.  See the License for the
  #    specific language governing permissions and limitations
  #    under the License.

  "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
  "Language-Team: LANGUAGE <[email protected]>\n"

  "Last-Translator: Subversion Developers <[email protected]>\n"
  "Language-Team: YOUR LANGUAGE <[email protected]>\n"

    make locale-gnu-po-update

    make locale-gnu-po-update PO=ll

  svn cat -r X ^/subversion/trunk/subversion/po/YY.po | \
    po-merge.py YY.po