SVN（Subversion）是一种类似于 Git 的版本控制系统。它可以通过命令行使用，也可以通过众多图形界面应用程序之一使用，例如 Tortoise SVN、SmartSVN 等更多工具。如果您是 SVN 的新手，我们建议您在决定哪个最适合您之前，先回顾一下 SVN 客户端对比。

本文档并非关于使用 SVN 的完整且详尽的解释，而是一份快速入门指南，旨在帮助您开始在 WordPress.org 上使用插件。如需更全面的文档，请参阅 The SVN Book。

我们将在此介绍一些与 WordPress.org 托管相关的 SVN 使用基础知识。SVN 的基本概念以及几乎所有代码存储库服务都保持不变。

如需更多信息，请查看以下文档：

SVN 和插件目录是一个 发布 存储库。与 Git 不同，您不应提交每一个小更改，因为这样做会降低性能。请仅将已完成的更改推送到您的 SVN 存储库。

概述

您的所有文件都将集中存储在服务器上的 svn 存储库中。从该存储库中，任何人都可以检出您插件文件的副本到其本地机器，但作为插件作者，只有您有权进行提交。这意味着您可以在本地机器上对文件进行修改、添加新文件或删除文件，并将这些更改上传回中央服务器。正是这种提交过程会更新存储库中的文件以及 WordPress.org 插件目录中显示的信息。

Subversion 会跟踪所有这些更改，以便您以后可以返回查看旧版本或修订版（如果需要使用）。除了记住每个单独的修订版外，您还可以指示 subversion 标记存储库的某些修订版以便于参考。标记非常适合 标记插件的不同发布版本，并且是确保 WordPress.org 上显示正确版本并为用户更新版本的唯一完全支持的方法。

您的账户

您的 SVN 账户将与您提交插件时使用的账户的相同用户名（而非电子邮件）一致。这也是您在 WordPress 论坛中使用的用户名。

WordPress.org 允许为您的账户设置 SVN 专用密码，这可以在 您的账户设置中进行。有关为何以及如何使用的更多信息，请参阅 此 Meta 指南。

请记住，大小写很重要——如果您的用户名是 JaneDoe，则必须使用大写的 J 和 D，否则 SVN 将失败。您可以在账户设置中查看您姓名的具体大小写：https://profiles.wordpress.org/me/profile/edit/group/3/?screen=svn-password

SVN 文件夹

所有 SVN 存储库中默认创建三个目录。

/assets/
/tags/
/trunk/

/branches/ 目录不再默认创建，因为它通常未被使用。

Trunk

不要将您的主插件文件放在 trunk 的子文件夹中，例如 /trunk/my-plugin/my-plugin.php，因为这会破坏下载。您可以使用子文件夹存放包含的文件。

/trunk 目录是您的插件代码应存放的位置。Trunk 可以被视为最新和最优秀的代码，但这不一定是最新的稳定代码。Trunk 用于开发版本。希望 trunk 中的代码始终是可运行的代码，但由于它不一定是“稳定”版本，因此偶尔可能会出现错误。对于简单的插件，trunk 可能是唯一存在的代码版本，这也是可以的。

即使您在其他地方进行开发工作（例如 Git 存储库），我们也建议您保持 trunk 文件夹与您的代码同步，以便轻松进行 SVN 比较。

Tags

/tags 目录是存放插件版本的地方。您将在此处的子目录中使用与插件版本相同的版本号。始终使用标记文件夹和正确的版本控制非常重要，以确保您的用户获得正确的代码。

插件的 1.0 版本将位于 /tags/1.0，1.1 版本将位于 /tags/1.1，依此类推。

我们强烈鼓励使用 语义软件版本控制。

资源文件

另请参阅：您的插件资源如何工作

资源文件目录是存放截图、头部图像和插件图标的位置。目录中的一些旧插件可能在 /trunk 中有截图文件，但这不推荐。所有新插件应将截图放在 /assets 中。这样可以保持插件的文件大小较小，因为不需要将截图随插件本身一起发送到 WordPress 安装中。

分支

/branches/ 目录不再默认创建，因为它几乎未被使用。此部分可视为已弃用，仅用于信息目的。

/branches 目录是您可以用来存储插件分支的地方。也许是处于开发中的版本或测试代码等。

WordPress.org 系统完全不使用 branches 目录做任何事情，它仅供开发者根据需要自行使用。由于不再默认创建，您可以忽略它，因为您不再需要它。

最佳实践

为了使您的代码对其他开发人员最易访问，以下做法被认为是最优的。

不要使用 SVN 进行开发

这通常令人困惑。与 GitHub 不同，SVN 旨在作为发布系统，而不是开发系统。您不需要提交和推送每一个小更改，事实上这样做对系统有害。每次您将代码推送到 SVN 时，它会重新构建 SVN 中所有版本的所有 zip 文件。这就是为什么有时您的插件更新可能需要长达 6 小时才能显示的原因。相反，您应该在准备就绪时推送一次。

使用 trunk 文件夹存放代码

许多人将 trunk 用作占位符。虽然可以简单地更新 trunk 中的 readme.txt 文件并将所有内容放在标记文件夹中，但这会使比较代码中的任何更改变得更加困难。相反，trunk 应包含您代码的最新版本，即使该版本是 beta 版。

始终标记发布版本

虽然可以将 trunk 用作插件的稳定标记，但该功能实际上不受支持也不推荐。相反，发布版本应正确标记并迭代。这将确保与任何自动更新器的完全兼容性，并在您的代码出现问题时允许回滚。

从 trunk 创建标记

您不应直接将代码推送到标记文件夹，而应编辑 trunk 中的代码（包括 readme 中的稳定版本），然后复制trunk 中的代码到新标记。

这不仅使查看任何更改变得更加容易，而且由于 SVN 仅更新已更改的代码，因此您将进行更小的提交。这将为您节省时间并减少潜在错误（例如更新到错误的稳定标记并向用户推送有问题的代码）。

不要担心标记文件夹在短期内不存在。您可以使用 svn cp 将 trunk 复制到标记文件夹，然后同时推送到 SVN。

如果您在本地操作，则可以一次性更新 trunk 并从中创建标记。检出存储库的根目录，更新 /trunk 中的文件，然后执行 svn copy /trunk /tags/1.2.3（或任何版本号），然后一次性提交所有内容。SVN 是一个基于差异的系统，只要您使用 svn 执行复制操作，它就会保留历史记录并使其他人轻松跟随。

示例

开始新插件

要启动您的插件，您需要将已有的文件添加到新的 SVN 仓库中。

首先，在您的机器上创建一个本地目录来存放 SVN 仓库的副本：

$ mkdir my-local-dir

接下来，检出预构建的仓库

$ svn co https://plugins.svn.wordpress.org/your-plugin-name my-local-dir
> A my-local-dir/trunk
> A my-local-dir/branches
> A my-local-dir/tags
> Checked out revision 11325.

在我们的示例中，subversion 已将中央 SVN 仓库中的所有目录（“A”代表“add”）添加到您的本地副本中。

要添加您的代码，请导航到 my-local-dir 文件夹：$ cd my-local-dir

现在您可以使用命令行中的复制/粘贴命令或通过拖放将文件添加到您本地仓库副本的 trunk/ 目录中。选择您感到舒适的方式即可。

不要将您的主插件文件放在 trunk 的子文件夹中，例如 /trunk/my-plugin/my-plugin.php，因为这会破坏下载。您可以为包含的文件使用子文件夹。

一旦您的文件位于 trunk 文件夹中，您必须让 subversion 知道您希望将这些新文件添加回中央仓库。

$ cd my-local-dir
my-local-dir/ $ svn add trunk/*
> A trunk/my-plugin.php
> A trunk/readme.txt

在添加完所有文件后，您将把更改提交回中央仓库。

my-local-dir/ $ svn ci -m 'Adding first version of my plugin'
> Adding trunk/my-plugin.php
> Adding trunk/readme.txt
> Transmitting file data .
> Committed revision 11326.

所有提交都必须包含提交信息。

如果提交因“Access forbidden”而失败，并且您知道您拥有提交权限，请在提交命令中添加您的用户名和密码。

my-local-dir/ $ svn ci -m 'Adding first version of my plugin' --username your_username --password your_password

请记住您的用户名是区分大小写的。

编辑现有文件

一旦您的插件位于目录中，您可能需要在某个时候编辑代码。

首先进入您本地仓库副本并确保它是最新的。

$ cd my-local-dir/
my-local-dir/ $ svn up
> At revision 11326.

在上述示例中，我们已经是最新的。如果中央仓库中有更改，它们将被下载并合并到您的本地副本中。

现在您可以使用您喜欢的任何编辑器编辑需要更改的文件。

如果您不使用 SVN GUI 工具（如 SubVersion 或 Coda），在做出更改后，您仍然可以检查并查看您的本地副本与中央仓库之间的差异。首先我们检查本地副本的状态：

my-local-dir/ $ svn stat
> M trunk/my-plugin.php

这告诉我们我们的本地 trunk/my-plugin.php 与我们从中央仓库下载的副本不同（“M”代表“modified”）。

让我们看看该文件中具体发生了什么变化，以便我们可以检查并确保一切正常。

my-local-dir/ $ svn diff
> * What comes out is essentially the result of a
  * standard `diff -u` between your local copy and the
  * original copy you downloaded.

如果一切看起来良好，那么是时候将这些更改提交到中央仓库了。

my-local-dir/ $ svn ci -m "fancy new feature: now you can foo *and* bar at the same time"
> Sending trunk/my-plugin.php
> Transmitting file data .
> Committed revision 11327.

现在您已经成功更新了 trunk。

“标记”新版本

每次您正式发布插件时，您都应该标记该发布版本的代码副本。这可以让您的用户轻松获取最新（或旧）版本，让您更容易跟踪更改，并让 WordPress.org 插件目录知道它应该告诉人们下载哪个版本的插件。

首先将您的代码复制到 tags/ 目录中的子目录。为了 WordPress.org 插件浏览器的利益，新的子目录应始终看起来像一个版本号。2.0.1.3 很好。Cool hotness tag 是不好的。

我们希望使用 svn cp 而不是常规的 cp，以便利用 SVN 的功能。

my-local-dir/ $ svn cp trunk tags/2.0
> A tags/2.0

一如既往，提交更改。

my-local-dir/ $ svn ci -m "tagging version 2.0"
> Adding         tags/2.0
> Adding         tags/2.0/my-plugin.php
> Adding         tags/2.0/readme.txt
> Committed revision 11328.

在标记新版本时，请记住更新 trunk/readme.txt 中的 Stable Tag 字段为新版本。

恭喜！您已更新了代码！

备注

不要将任何您不愿意并准备好部署给使用您的插件的所有人的内容放入 SVN。这包括供应商文件、.gitignore 和所有内容。

您也永远不应该上传 zip 文件。像大多数代码仓库系统一样，SVN 期望您上传单个文件。

另请参阅