參與社群 ¶

雖然 Subversion 最初是由 CollabNet 贊助和託管（https://www.collab.net/），但它是一個真正的開源專案，採用 Apache 授權條款，版本 2.0。許多 Subversion 開發人員由其雇主支付薪水來改善 Subversion，而其他許多人只是單純對建置更好的版本控制系統有興趣的優秀志工。

社群主要透過 IRC、郵件清單和 Subversion 儲存庫存在。若要參與

• 在 #svn-dev 頻道加入我們於 irc.libera.chat（使用 網路介面 或 Matrix 或任何 IRC 軟體；已封存 於此）。

• 加入「開發」、「提交」和「公告」郵件清單。開發清單 dev@subversion.apache.org 是幾乎所有討論進行的地方。所有開發問題都應張貼於此，儘管您可能想要先查看清單封存。提交清單會收到自動提交電子郵件。請參閱 https://subversion.dev.org.tw/mailing-lists.html 以取得詳細資訊。

• 從 https://svn.apache.org/repos/asf/subversion/trunk/ 取得最新開發原始碼
  新的開發始終在主幹上進行。錯誤修正、增強功能和新功能會從主幹回傳到各個發行分支。

多年來，Subversion 社群每年都會在柏林舉辦一次黑客松：2016、2015、2014、2013、2012、2011 和 2010 [連結來自 archive.org，有些媒體連結失效]。

有許多方式可以加入這個專案，包括撰寫程式碼、測試和/或協助管理錯誤資料庫。如果您想貢獻一己之力，請查看

• 錯誤/問題資料庫 https://issues.apache.org/jira/projects/SVN/issues

若要提交程式碼，請將您的程式碼補丁寄送至 dev@subversion.apache.org。不對，請先閱讀完本檔案的其餘部分，然後再開始將程式碼補丁寄送至 dev@subversion.apache.org。 :-)

若要協助管理問題資料庫，請閱讀問題摘要，尋找並測試無效或重複的問題。這兩種情況都很常見，前者是因為錯誤通常會在不知不覺中，因為程式碼中的其他變更而得到修正，後者是因為人們有時會在沒有注意到問題已經被回報的情況下，提交問題。如果您不確定某個問題，請在 dev@subversion.apache.org 發布問題。("Subversion：我們在此協助您協助我們！")

協助的另一種方式是在某些平台上設定 Subversion 的自動建置和測試套件執行，並將輸出寄送至 notifications@subversion.apache.org 郵件清單。請在 郵件清單頁面 查看更多詳細資訊。

最後，儘管 Subversion 專案的線上性質以及由此產生的抽象人際接觸，但重要的是要了解，所有貢獻的背後都有真實的人。以你希望被對待的方式對待所有其他社群成員。檢閱貢獻，而不是貢獻者；不要惹惱他人，也不要輕易被惹惱。

理論與文件 ¶

1. 設計

   一份設計規範寫於 2000 年 6 月，有點過時了。但它仍然對儲存庫的內部運作和 Subversion 的各個層級提供了良好的理論介紹。

2. API 文件

   請參閱公開 API 文件部分以取得更多資訊。

3. Delta 編輯器

   Karl Fogel 為 O'Reilly 的 2007 年書籍美麗的程式碼：領先的程式設計師說明他們的思考方式撰寫了一章，涵蓋Subversion 的 delta 編輯器介面的設計和使用。

4. 網路通訊協定

   WebDAV 使用文件是 Subversion 的 DAV 網路通訊協定的簡介，它是一種 HTTP 的擴充方言，並使用以「http://」或「https://」開頭的 URL。

   SVN 通訊協定文件包含 Subversion ra_svn 網路通訊協定的正式說明，這是一種在埠 3690（預設）上的自訂通訊協定，其 URL 以「svn://」或「svn+ssh://」開頭。

5. 使用者手冊

   由 O'Reilly 出版的《Subversion 版本控制》是一本詳細說明如何有效使用 Subversion 的書籍。該書的文字是免費的，並且積極地進行修訂。線上版本可在https://svnbook.dev.org.tw/取得。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 Portable Runtime (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 <kfogel@red-bean.com>
   To: dev@subversion.tigris.org
   Subject: branch liberalization (was: Elego tree conflicts work)
   Date: Tue, 20 Nov 2007 10:49:38 -0800
   Message-Id: <87y7cswy4d.fsf@red-bean.com>

------------------------------------------------------------------------
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 專案中版本管理員的角色是處理將程式碼穩定化、封裝並發佈給一般大眾的程序。如果我們正在建造飛機，版本管理員將會是查看建造清單、在機身上噴上航空公司標誌，並將成品交付給客戶的人。

因此，擔任版本管理員並未與任何實際開發相關。您必須完成的所有工作都是非編碼的：協調人員、集中資訊，並成為宣告新的穩定版本之公開發言人。版本管理員必須執行的許多任務都是重複性的，而且未自動化，原因可能是因為尚未有人分解並撰寫工具，或者因為這些任務需要人工驗證，這使得自動化有些多餘。您可以在 製作 Subversion 版本 區段中閱讀更多有關版本程序的資訊。

您可能在這個階段認為版本管理員的職責並不光鮮亮麗，而您說得沒錯。如果您正在尋找一個能為專案帶來名聲和財富的職位，您最好實作主幹中真正需要完成的事項。如果您正在尋找能真正幫助不在乎版本的人員專注於程式碼的事項，那麼版本管理員就是您的最佳選擇。

為了鼓勵更廣泛的散布版本管理知識，RM 角色目前在各個 受害者 志工之間輪替。

修補程式管理員 ¶

Subversion 通常會有一個修補程式管理員，其工作是觀察 dev@ 郵件清單並確保沒有修補程式「從縫隙中溜走」。

這表示要觀察每個包含「[PATCH]」郵件的討論串，並根據討論串的進度採取適當的行動。如果討論串自行解決（因為修補程式已提交，或因為達成共識認為不需要套用修補程式，或其他原因），則不需要採取進一步的行動。但是，如果討論串在沒有明確決議的情況下逐漸消失，則需要將修補程式儲存在問題追蹤器中。這表示將會在追蹤器中的某個問題中新增該修補程式周圍所有討論串的摘要，以及相關郵件清單封存的連結。對於解決現有問題追蹤器項目的修補程式，則將修補程式儲存到該項目中。否則，會歸檔一個正確類型的問題（「缺陷」、「功能」或「增強」（不是「修補程式」）），將修補程式儲存到該新問題中，並在問題中記錄「patch」關鍵字。

修補程式管理員需要對 Subversion 有基本的技術了解，以及能夠瀏覽討論串並粗略了解是否已達成共識，以及如果是的話，達成什麼樣的共識。不需要實際的 Subversion 開發經驗或提交權限。熟練使用自己的郵件閱讀軟體是可選的，但建議 :-).

目前的修補程式管理員是：Gavin 'Beau' Baumanis <gavin@thespidernet.com>。

程式碼模組化和介面可見性 ¶

Subversion 的程式碼和標頭檔案會沿著幾個關鍵路線區分：特定於程式庫與程式庫間；公開與私有。這種分離主要是因為我們專注於適當的模組化和程式碼組織，但也因為我們作為廣泛採用的公開 API 的提供者和維護者的承諾。當您在 Subversion 中撰寫新函式時，您需要仔細考慮這些事情，在進行的同時自問一些問題

「我的新程式碼的使用者是否只限於單一程式庫中的特定原始碼檔案？」如果是這樣，您可能需要在同一個原始碼檔案中使用靜態函式。

「我的新函式是否為此程式庫中的其他原始碼需要使用，但程式庫*外部*不需要使用的類型？」如果是這樣，您需要使用非靜態、雙底線命名的函式（例如 svn_foo__do_something），其原型在適當的特定於程式庫的標頭檔案中。

「我的程式碼是否需要從不同的程式庫中存取？」在這裡，您需要回答一些額外的問題，例如「我的程式碼應該存在於我原本打算放置的程式庫中，還是應該存在於更通用的公用程式庫中，例如 libsvn_subr？」無論如何，您現在正在考慮使用程式庫間標頭檔案。但在您決定使用哪一個之前，請參閱下一個問題...

「我的程式碼是否具備乾淨、可維護的 API，可以合理地永久維護，並為 Subversion 公共 API 提供價值？」如果是，您將在 subversion/include/ 內部立即將原型新增至公共 API。如果不是，請仔細檢查您的計畫，也許您尚未選擇抽象功能的最佳方式。但有時，函式庫確實需要共用某些功能，而這些功能對 Subversion 本身以外的其他軟體來說可能沒有用。在這種情況下，請使用 subversion/include/private/ 中的私人標頭檔。

程式碼風格 ¶

Subversion 使用 ANSI C，並遵循 GNU 編碼標準，但我們不會在函式名稱和其參數清單的開頭括號之間放置空格。Emacs 使用者可以載入 svn-dev.el 以取得正確的縮排行為（如果適當地設定 `enable-local-eval`，這裡的大部分原始檔將自動載入它）。

請閱讀 https://gnu.dev.org.tw/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`。這樣的人員並不像您想像的那麼少，如果您想成為其中一員，請將 (require 'page-ext) 新增至您的 .emacs，然後輸入 C-x C-p C-h。

錯誤訊息慣例 ¶

下列慣例套用於錯誤訊息

• 僅在有資訊要新增至 subversion/include/svn_error_codes.h 中的「一般錯誤訊息」時，提供特定錯誤訊息。

• 訊息以大寫字母開頭。

• 嘗試將訊息保持在 70 個字元以下。

• 不要以句點（「.」）結尾錯誤訊息。

• 不要在錯誤訊息中包含換行字元。

• 使用單引號引述資訊（例如「『一些資訊』」）。

• 不要在錯誤訊息中包含錯誤發生的函式名稱。如果 Subversion 使用「--enable-maintainer-mode」組態旗標編譯，它會自行提供此資訊。

• 在錯誤字串中包含路徑或檔案名稱時，請務必引述它們（例如「找不到『/path/to/repos/userfile』」）。

• 在錯誤字串中包含路徑或檔案名稱時，請務必在包含之前使用 svn_dirent_local_style() 轉換它們（因為傳遞至 Subversion API 和從 Subversion API 傳回的路徑假設為 正規形式）。

• 不要使用 Subversion 特定的縮寫（例如使用「儲存庫」代替「repo」，使用「工作副本」代替「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 函式引數，它同時作為結果池和暫存池。）

透過使用 iterpool 迴圈限制資料，您可以確保 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 物件數量即可，當該池被清除或銷毀時，它們將同時消失。

另請參閱 例外處理 部分，了解當池被銷毀時如何清除與池相關的資源的詳細資訊。

總之

• 物件不應該有自己的池。物件配置到由建構函式的呼叫者定義的池中。呼叫者知道物件的生命週期，並將透過池管理它。

• 函數不應建立/銷毀其運作的池，它們應使用呼叫者提供的池。同樣地，呼叫者更了解函數將如何使用、使用頻率、使用次數等，因此，它應負責函數的記憶體使用。

  例如，想一下一個在緊密迴圈中多次呼叫的函數。呼叫者在每次反覆運算中清除暫存池。因此，建立內部子池是不必要的，而且可能造成顯著的負擔；函數應僅使用傳入的池。

• 每當發生無界反覆運算時，應使用反覆運算子池。

• 根據以上所有內容，將池傳遞給每個函數是相當必要的。由於物件不會為自己記錄池，而且呼叫者應始終管理記憶體，因此每個函數需要一個池，而不是依賴某些隱藏的魔法池。在有限的情況下，物件可能會記錄用於其建構的池，以便它們可以建構子部分，但應仔細檢查這些情況。

另請參閱 追蹤記憶體外洩，以取得診斷池使用問題的提示。

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 來儲存其資料。這也適用於「訊息」字串。假設 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. 向上擲出錯誤，將其包裝在新的錯誤結構中，方法是將其包含為「子項」引數

              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() 巨集會建立包裝錯誤。這有助於開發人員判斷錯誤原因，並可以使用 --enable-maintainer-mode 選項在 configure 中啟用。

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 將它們轉換為您平台預期的形式。

• 只使用空白來縮排程式碼，絕不使用 tab。Tab 顯示寬度沒有標準化，而且使用空白的縮排更容易手動調整。

• 將程式碼限制在 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」或「@作者 foo」這類的文字）。這是為了避免地盤主義——即使檔案只有一個作者，我們也希望確保其他人能自由地進行變更。如果有人看起來對檔案宣示了個人所有權，人們可能會不必要地猶豫。

• 在一個句子的結尾和下一個句子的開頭之間放置兩個空格。這有助於閱讀，並允許人們使用他們的編輯器的句子移動和操作命令。

• 在整個程式碼中還有許多其他不言而喻的慣例，只有當有人無意中沒有遵循它們時才會被注意到。只要試著對事情的執行方式保持敏銳的眼光，當有疑問時，請詢問。

撰寫日誌訊息 ¶

每個提交都需要一個日誌訊息。

日誌訊息的預期受眾是已經熟悉 Subversion 但不一定熟悉此特定提交的開發人員。通常，當有人回去閱讀變更時，他不再記住該變更周圍的所有內容。即使他是變更的作者，這也是正確的！所有討論、郵件清單串聯和所有其他內容都可能被遺忘；變更內容的唯一線索來自日誌訊息和 diff 本身。人們也會驚人頻繁地重新檢視變更：例如，在原始提交幾個月後，現在變更正被移植到維護分支。

日誌訊息是變更的引言。

• 如果您正在分支上工作，請在您的日誌訊息前加上

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

• 以一行指示變更的一般性質來開始您的日誌訊息，並在必要時加上一個描述性的段落。

這不僅有助於讓開發人員進入正確的心態來閱讀日誌訊息的其餘部分，而且還能很好地與「ASFBot」機器人配合使用，該機器人會將每個提交的第一行回顯到 IRC 等即時論壇中。（有關詳細資訊，請參閱 https://wilderness.apache.org/ ）

如果提交只是一個檔案的一個簡單變更，那麼你可以放棄一般描述，直接進入詳細描述，採用以下所示的標準檔名然後符號格式。

在整個日誌訊息中，請使用完整的句子，而不是句子片段。片段通常較為含糊，而且寫出你的意思只需要多花幾秒鐘。某些片段，例如「文件修正」、「新檔案」或「新函式」是可以接受的，因為它們是標準慣用語，所有進一步的詳細資訊都應該出現在原始碼中。

日誌訊息應命名每個受影響的函式、變數、巨集、makefile 目標、語法規則等，包括在此提交中被移除的符號名稱。這有助於人們稍後搜尋日誌。不要將名稱隱藏在萬用字元中，因為 globbed 部分可能是其他人稍後搜尋的內容。例如，這是錯誤的

   * 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.

如果您的變更與問題追蹤器中的特定問題相關，請在記錄訊息中包含類似「問題 #N」的字串，但請務必仍摘要說明變更的內容。例如，如果一個修補程式解決了問題 #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 <jrandom@example.com>

如果有多人撰寫程式碼，請將每個人列在不同的行中，並確保每個續行都以空白開頭。非提交者應列出姓名（如果已知）和電子郵件。完整和部分提交者應列出其在 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 <jrandom@example.com>
             Enrico Caruso <codingtenor@codingtenor.com>
             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 <jrandom@example.com>

如果有人提出有用的建議，但並未撰寫程式碼，請使用「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 <eeyes@example.com>

一個欄位可以有多行，而一個日誌訊息可以包含任何欄位組合

   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 <jrandom@example.com>
             Enrico Caruso <codingtenor@codingtenor.com>
             me
   Found by: J. Random <jrandom@example.com>
   Review by: Eagle Eyes <eeyes@example.com>
              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 <jrandom@example.com>
   (Tweaked by me.)

   Review by: Eagle Eyes <eeyes@example.com>
              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 現有的記錄訊息，以了解如何實際使用這些欄位。主幹工作副本頂端的這個指令會有幫助

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

注意：在某些提交訊息中看到的「Approved by: 」欄位與這些歸功欄位完全無關，而且通常不會由腳本剖析。它只是用於指出誰核准了部分提交者的提交（在他們平常的區域之外），或（在合併至釋出分支的情況下）誰投票贊成合併變更的標準語法。

Github ¶

Subversion 儲存庫已鏡像至 https://github.com/apache/subversion/ 上的 GitHub。

有些使用者可能會在 GitHub 中建立拉取要求。如果程式碼提交至 Subversion 儲存庫，請務必在記錄訊息中包含文字，以自動關閉拉取要求

This fixes #NNN in GitHub

若要在不提交程式碼的情況下管理拉取要求，您的 GitHub 帳戶必須連線至您的 ASF ID，而且 ASF Infra 必須將 triager 角色指派給您的帳戶。

unix 下的組態/建置系統 ¶

Greg Stein 為 Subversion 編寫了一個自訂建置系統，Subversion 一直在使用 `automake` 和遞迴 Makefile。現在它使用單一頂層 Makefile，從 Makefile.in 產生（在版本控制下保留）。`Makefile.in` 反過來包含 `build-outputs.mk`，由 `gen-make.py` 腳本從 `build.conf` 自動產生。因此，後兩者在版本控制下，但 `build-outputs.mk` 不在。

以下是 Greg 描述系統的原始郵件，後面有一些關於駭入它的建議

   From: Greg Stein <gstein@lyra.org>
   Subject:  new build system (was: Re: CVS update: MODIFIED: ac-helpers ...)
   To: dev@subversion.tigris.org
   Date: Thu, 24 May 2001 07:20:55 -0700
   Message-ID: <20010524072055.F5402@lyra.org>

   On Thu, May 24, 2001 at 01:40:17PM -0000, gstein@tigris.org 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 <kfogel@collab.net>
   To: dev@subversion.tigris.org
   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。

建置農場 ¶

ASF 基礎架構 團隊管理一個 BuildBot 建置/測試農場。Subversion 專案的 Buildbot 瀑布位於此處

• 生產建置
• 回溯和 RAT 狀態
• 相容性測試
• 整個農場

有關建置服務的更多資訊，請前往 ci2.apache.org。

如果您想接收有關 buildbot 建置和測試失敗的通知，請訂閱 notifications@ 郵件清單。

Buildbot 在 Infra 儲存庫 中進行設定，特別是 subversion.py 檔案。

在撰寫程式碼之前撰寫測試案例 ¶

From: Karl Fogel <kfogel@collab.net>
Subject: writing test cases
To: dev@subversion.tigris.org
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 輸出

• 只要使用 --enable-maintainer-mode 配置 svn，就會啟用 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 <kfogel@collab.net>
   Subject: Please ask on the list before filing a new issue.
   To: dev@subversion.tigris.org
   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 版本

此文件通常可以分為三個部分，依據具體性遞增

• 高階版本規劃和政策，例如版本編號和相容性。這回答了「什麼時候會建立 tarball？」和「tarball 的內容應該是什麼？」等問題。
• 在需要建立版本時應採取的步驟。此區段說明了「如何管理版本？」的問題。
• 如何建構一組版本 tarball。此區段討論了從儲存庫中的原始程式碼轉換為一組可散發的 .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 <LL@li.org>\n"

  "Last-Translator: Subversion Developers <dev@subversion.apache.org>\n"
  "Language-Team: YOUR LANGUAGE <dev@subversion.apache.org>\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