Using Subversion

SVN (Subversion) は、Git と同様のバージョン管理システムです。コマンドラインや、Tortoise SVNSmartSVNなどの数多くのGUIアプリケーションを使って使用することができます。SVN を初めて使う方は、どのクライアントが最適かを決める前に、SVN クライアントの比較をご覧になることをお勧めします。

SVN, or Subversion, is a version control system similar to Git. It can be used via command line, or one of numerous GUI applications, such as Tortoise SVN, SmartSVN, and more. If you’re new to SVN, we recommend reviewing a comparison of SVN clients before deciding which is best for you.

このドキュメントは、SVN を使用するための完全で強固な説明ではなく、WordPress.org でプラグインを使い始めるための簡単な入門書です。より包括的なドキュメントについては、The SVN Bookをご覧ください。

This document is not a complete and robust explanation for using SVN, but more a quick primer to get started with plugins on WordPress.org. For more comprehensive documentation, see The SVN Book.

ここでは、WordPress.org のホスティングに関連する SVN の使用について、基本的なことを説明します。SVN をはじめ、ほぼすべてのコードリポジトリサービスの基本的なコンセプトは変わりません。

We’ll describe here some of the basics about using SVN as it relates to WordPress.org hosting. The basic concepts of SVN, and nearly all code repository services, remain the same.

その他の情報については、これらの文書をご覧ください。

For additional information, please see these documents:

Warning:SVNとPlugin Directoryはリリースリポジトリです。Git とは異なり、小さな変更をすべてコミットしてはいけません。そうするとパフォーマンスが低下してしまいます。完成した変更のみをSVNリポジトリにプッシュしてください。
Warning: SVN and the Plugin Directory are a release repository. Unlike Git, you shouldn’t commit every small change, as doing so can degrade performance. Please only push finished changes to your SVN repository.

Overview Overview

あなたのファイルはすべて、私たちのサーバー上のsvnリポジトリに集中的に保管されます。そのリポジトリから、誰でも自分のローカルマシンにプラグインファイルのコピーをチェックアウトすることができますが、プラグイン作者としては、あなただけがチェックインする権限を持っています。つまり、ローカルマシン上でファイルに変更を加えたり、新しいファイルを追加したり、ファイルを削除したりして、それらの変更を中央サーバーにアップロードすることができるのです。リポジトリ内のファイルと、WordPress.org Plugin Directory に表示される情報の両方が更新されるのは、このチェックインのプロセスによるものです。

All your files will be centrally stored in the svn repository on our servers. From that repository, anyone can check out a copy of your plugin files onto their local machine, but, as a plugin author, only you have the authority to check in. That means you can make changes to the files, add new files, and delete files on your local machine and upload those changes back to the central server. It’s this process of checking in that updates both the files in the repository and also the information displayed in the WordPress.org Plugin Directory.

Subversionはこれらの変更をすべて記録しているので、必要に応じて古いバージョンやリビジョンに戻って見ることができます。個々のリビジョンを記憶するだけでなく、参照しやすいようにリポジトリの特定のリビジョンにタグを付けるようにsubversionに指示することもできます。タグは、プラグインの異なるリリースをラベル付けするのに適しており、正しいバージョンがWordPress.orgで確認され、ユーザーのために更新されることを保証する、唯一の完全にサポートされた方法です。

Subversion keeps track of all these changes so that you can go back and look at old versions or revisions later if you ever need to. In addition to remembering each individual revision, you can tell subversion to tag certain revisions of the repository for easy reference. Tags are great for labeling different releases of your plugin and are the only fully supported method of ensuring the correct versions are seen on WordPress.org and updated for users.

Top ↑

Your Account Your Account

SVN 用のアカウントは、プラグインを提出したときに使用したアカウントと同じユーザー名(メールではありません)になります。このユーザー名は、WordPress のフォーラムでも使用するユーザー ID です。

Your account for SVN will be the same username (not the email) of the account you used when you submitted the plugin. This is the user ID you use for the WordPress forums as well.

ユーザー名が JaneDoe の場合、大文字の J と D を使用しなければ SVN は失敗しますので、大文字の重要性を覚えておいてください。自分の名前の具体的な大文字表記については、 https://profiles.wordpress.org/me/profile/edit/group/1/で確認できます。

Remember, capitalization matters — if your username is JaneDoe, then you must use the capital J and D or else SVN will fail. You can see the specific capitalization of your name at  https://profiles.wordpress.org/me/profile/edit/group/1/

パスワードをリセットする必要がある場合は、login.wordpress.orgにアクセスしてください。

If you need to reset your password, go to login.wordpress.org

Top ↑

SVN Folders SVN Folders

すべてのSVNリポジトリには、デフォルトで3つのディレクトリが作成されています。

There are three directories created by default in all SVN repositories.

/assets/
/tags/
/trunk/

/branches/ ディレクトリは、使用されていなかったため、デフォルトでは作成されなくなりました。

The /branches/ directory is no longer created by default, as it was unused.

Trunk Trunk

Warning:/trunk/my-plugin/my-plugin.phpのように、mainプラグインファイルをtrunkのサブフォルダーに置かないでください。インクルードファイルにはサブフォルダを使用することができます。

Warning: Do not put your main plugin file in a subfolder of trunk, like /trunk/my-plugin/my-plugin.php as that will break downloads. You may use subfolders for included files.

/trunkディレクトリは、あなたのプラグインのコードが置かれるべき場所です。トランクは最新で最高のコードと考えることができますが、これは必ずしも最新のstableコードではありません。Trunkは開発バージョンのためのものです。うまくいけば、trunkにあるコードは常に動作するコードであるべきですが、必ずしも「安定した」バージョンではないので、時々はバグがあるかもしれません。シンプルなプラグインの場合、trunkがそのコードの唯一のバージョンであるかもしれませんが、それはそれで構いません。

The /trunk directory is where your plugin code should live. The trunk can be considered to be the latest and greatest code, however this is not necessarily the latest stable code. Trunk is for the development version. Hopefully, the code in trunk should always be working code, but it may be buggy from time to time because it’s not necessarily the “stable” version. For simple plugins, the trunk may be the only version of the code that exists, and that’s fine as well.

開発作業を別の場所(gitリポジトリなど)で行っている場合でも、SVNの比較を容易にするために、trunkフォルダにコードを最新の状態で保存しておくことをお勧めします。

Even if you do your development work elsewhere (like a git repository), we recommend you keep the trunk folder up to date with your code for easy SVN compares.

Top ↑

Tags Tags

/tagsディレクトリは、プラグインのバージョンを置く場所です。ここのサブディレクトリには、プラグインのバージョン管理と同じバージョン番号を使用します。ユーザーが正しいコードを入手できるように、常にタグフォルダと適切なバージョン管理を行うことが重要です。

The /tags directory is where you put versions of the plugin. You will use the same version numbers for the sub-directories here as you do for your plugin versioning. It is important that you always use tag folders and proper versioning to ensure your users get the correct code.

バージョン1.0であれば、 /tags/1.0となり,バージョン1.1となれば、/tags/1.1という風になります。

Version 1.0 of the plugin will be in /tags/1.0, version 1.1 would be in /tags/1.1, and so forth.

私たちは、semantic software versioningの使用を強く推奨します。

We strongly encourage the use of semantic software versioning.

Top ↑

Assets Assets

Note: こちらもご覧ください。プラグインアセットの仕組み

Assetsには、スクリーンショット、ヘッダー画像、プラグインのアイコンなどが置かれます。古いプラグインでは、スクリーンショットを/trunkに置いている場合がありますが、これは推奨されません。すべての新しいプラグインは、スクリーンショットを/assetsに置くべきです。これにより、プラグインのファイルサイズを小さくすることができます。プラグインと一緒にWordPressのインストールにスクリーンショットを送信する必要がないからです。

Assets is where your screenshots, header images, and plugin icons reside. Some older plugins in the directory may have screenshot files in /trunk instead, however this is not recommended. All new plugins should put their screenshots in /assets. This keeps the filesizes of plugins small, as it is not necessary to send screenshots to WordPress installations along with the plugin itself.

Top ↑

Branches Branches

/branches/ディレクトリは、ほとんど使用されていなかったため、デフォルトでは作成されなくなりました。このセクションは非推奨と考えられ、情報提供の目的でのみ利用できます。

The /branches/ directory is no longer created by default, as it was largely unused. This section can be considered deprecated and is available only for informational purposes.

/branchesディレクトリは、プラグインのブランチを保存するために使用できる場所です。おそらく、開発中のバージョンやテストコードなどがあるでしょう。

The /branches directory is a place that you can use to store branches of the plugin. Perhaps versions that are in development, or test code, etc.

WordPress.org システムでは、branches ディレクトリは一切使用されておらず、厳密には開発者が必要に応じて使用するものと考えられています。デフォルトでは作成されないので、もはや必要ないので無視して構いません。

The WordPress.org system does not use the branches directory for anything at all, it’s considered to be strictly for developers to use as they need it. As it is no longer created by default, you can ignore it as you do not need it any longer.

Top ↑

Best Practices Best Practices

あなたのコードを他の開発者が最もアクセスしやすいようにするためには、以下のような方法が最適だと考えられます。

In order to make your code the most accessible for other developers, the following practices are considered to be optimum.

Top ↑

Don’t use SVN for development Don’t use SVN for development

これはよく混乱します。GitHubとは異なり、SVNは開発システムではなく、リリースシステムであることを意味します。小さな変更のたびにコミットしたりプッシュしたりする必要はありませんし、むしろそうすることでシステムに悪影響を及ぼします。SVNにコードをプッシュするたびに、SVN内のすべてのバージョンのzipファイルが再構築されます。これが、プラグインの更新が最大6時間も表示されないことがある理由です。代わりに、準備ができたときに一度だけプッシュするようにしてください。

This is often confusing. Unlike GitHub, SVN is meant to be a release system, not a development system. You don’t need to commit and push every small change, and in fact doing so is detrimental to the system. Every time you push code to SVN, it rebuilds all your zip files for all versions in SVN. This is why sometimes your plugin updates don’t show for up to 6 hours. Instead, you should push one time, when you’re ready to go.

Top ↑

Use the trunk folder for code Use the trunk folder for code

多くの人がtrunkをプレースホルダーとして使用しています。trunkのreadme.txtファイルを単純に更新して、すべてをtagフォルダに入れることは可能ですが、そうするとコードの変更点を比較するのが難しくなります。そうではなく、たとえベータ版であっても、トランクにはコードの最新版を置くべきです。

Many people use trunk as a placeholder. While it’s possible to simply update the readme.txt file in trunk and put everything in tag folders, doing so makes it more difficult to compare any changes in your code. Instead, trunk should contain the latest version of your code, even if that version is a beta.

Top ↑

Always Tag Releases Always Tag Releases

プラグインの安定版タグとしてtrunkを使用することは可能ですが、この機能は実際にはサポートされておらず、推奨もされていません。代わりに、リリースは適切にタグ付けされ、イテレートされるべきです。これにより、自動アップデータとの完全な互換性が確保され、コードに問題があった場合にはロールバックが可能になります。

While it’s possible to use trunk as a stable tag for plugins, this feature is not actually supported nor recommended. Instead, releases should be properly tagged an iterated. This will ensure full compatibility with any automatic updater, as well as allow for rollbacks should there be an issue with your code.

Top ↑

Create tags from trunk Create tags from trunk

コードをタグフォルダに直接プッシュするのではなく、trunkでコードを編集し、readmeで安定版を完成させ、その後trunkからコードを新しいタグにコピーしてください。

Instead of pushing your code directly to a tag folder, you should edit the code in trunk, complete with the stable version in the readme, and then copy the code from trunk to the new tag.

SVNは変更されたコードのみを更新するため、変更点を確認しやすくなるだけでなく、より小さなコミットを行うことができます。これにより、時間を節約し、潜在的なエラーを減らすことができます (間違った安定版タグに更新して、悪いコードをユーザーにプッシュしてしまうなど)。

Not only will this make it easier see any changes, you will be making smaller commits as SVN will only update the changed code. This will save you time and reduce potential errors (such as updating to the wrong stable tag and pushing bad code to users).

しばらくの間、tagフォルダが存在しなくても心配ありません。svn cpを使ってtrunkをtagにコピーし、同時にSVNにアップすることができます。

Don’t worry about the tag folder not existing for a short while. You can use svn cp to copy trunk to the tag and then push them up to SVN at the same time.

ローカルで運用しているのであれば、trunk の更新とそこからのタグ作成を一度に行うことができます。リポジトリのルートをチェックアウトし、/trunk のファイルを更新した後、svn copy /trunk /tags/1.2.3 (またはバージョン番号が何であれ)をコピーし、全体を一度にコミットします。SVNは差分に基づいたシステムであり、svnを使ってコピー操作を行う限り、履歴を保持し、他の人がフォローしやすいようにすべてを行います。

If you are operating locally, then you can update trunk and create tags from it all in one go. Checkout the root of your repository, update the files in /trunk, then svn copy /trunk /tags/1.2.3 (or whatever the version number is) and then commit the whole thing in one go. SVN is a system based on differences, and as long as you use svn to do the copy operation, then it preserves history and makes everything easy for others to follow along with.

Top ↑

Delete old versions Delete old versions

SVNはリリースリポジトリなので、多くの開発者は古い(サポートされていない)バージョンのプラグインを削除することを選択しました。2019年現在、ビルドプロセスでは変更されたファイルを持つタグにのみ対応するため、古いバージョンのプラグインを削除してもリリースの高速化はされません。

Since SVN is a release repository, many developers chose to remove older (non-supported) versions of their plugins. As of 2019, this no longer speeds up releases, as the build process only addresses tags with changed files.

Top ↑

Examples Examples

Top ↑

Starting a New Plugin Starting a New Plugin

プラグインを開始するには、すでにあるファイルを新しいSVNリポジトリに追加する必要があります。

To start your plugin, you need to add the files you already have to your new SVN repository.

まず、自分のマシンにSVNリポジトリのコピーを格納するローカルディレクトリを作成します。

First create a local directory on your machine to house a copy of the SVN repository:

$ mkdir my-local-dir

次に、bluit前のリポジトリをチェックアウトします。

Next, check out the pre-built repository

1
2
3
4
5
$ 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リポジトリからすべてのディレクトリをローカルコピーに追加しました("add "の "A")。

In our example, subversion has added ( “A” for “add” ) all of the directories from the central SVN repository to your local copy.

To add your code, navigate into the my-local-dir folder: $ cd my-local-dir

これで、コマンドラインからのコピー&ペーストや、ドラッグ&ドロップを使って、リポジトリのローカルコピーのtrunk/ディレクトリにファイルを追加できるようになりました。あなたの使いやすい方法でどうぞ。

Now you can add your files to the trunk/ directory of your local copy of the repository using copy/paste commands via command line, or dragging and dropping. Whatever you’re comfortable with.

Warning:/trunk/my-plugin/my-plugin.phpのように、メインのプラグインファイルをtrunkのサブフォルダに置かないでください。インクルードファイルにはサブフォルダを使用することができます。

Warning: Do not put your main plugin file in a subfolder of trunk, like /trunk/my-plugin/my-plugin.php as that will break downloads. You may use subfolders for included files.

ファイルがtrunkフォルダに入ったら、その新しいファイルを中央のリポジトリに戻したいことをsubversionに知らせなければなりません。

Once your files are in the trunk folder, you must let subversion know you want to add those new files back into the central repository.

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

すべてのファイルを追加した後、変更内容を中央のリポジトリにチェックインして戻します。

After you add all your files, you’ll check in the changes back to the central repository.

1
2
3
4
5
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.

すべてのチェックインには、コミットメッセージを入れることが義務付けられています。

It’s required to include a commit message for all checkins.

「Access forbidden」という理由でコミットが失敗し、しかし自分がコミット権限を持っていることがはっきりしている場合は、チェックインコマンドにユーザー名とパスワードを追加します。

If the commit fails because of ‘Access forbidden’ and you know you have commit access, add your username and password to the check-in command.

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

ユーザー名の大文字・小文字は区別されます。

Remember your username is case sensitive.

Top ↑

Editing Existing Files Editing Existing Files

プラグインをディレクトリに配置した後は、コードを編集する必要があります。

Once your plugin is in the directory, you will likely need to edit the code at some point.

まず、ローカルのリポジトリに入り、最新の状態になっていることを確認します。

First go into your your local copy of the repository and make sure it’s up to date.

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

上の例では、全てが最新の状態になっています。中央のリポジトリに変更があった場合、その変更はダウンロードされ、ローカルコピーにマージされているはずです。

In the above example, we’re all up to date. If there had been changes in the central repository, they would have been downloaded and merged into your local copy.

これで、変更が必要なファイルをお好みのエディターで編集することができます。

Now you can edit the file that needs changing using whatever editor you prefer.

SVN GUI ツール(Subversion や Coda など)を使用していない場合でも、変更後にローカルコピーとセントラルリポジトリの間で何が違うのかを確認することができます。まず、ローカルコピーの状態を確認します。

If you’re not using an SVN GUI tool (like SubVersion or Coda) you can still check and see what’s different between your local copy and the central repository after you make changes. First we check the status of the local copy:

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

これは、ローカルのtrunk/my-plugin.phpがセントラルリポジトリからダウンロードしたものとは異なることを示しています("M "は "modified")。

This tells us that our local trunk/my-plugin.php is different from the copy we downloaded from the central repository ( “M” for “modified” ).

そのファイルで何が変わったのかを確認して、それが正しいかどうかをチェックしましょう。

Let’s see what exactly has changed in that file, so we can check it over and make sure things look right.

1
2
3
4
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.

問題がなければ、変更した内容を中央のリポジトリにチェックインします。

If it all looks good then it’s time to check in those changes to the central repository.

1
2
3
4
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のアップデートが完了しました。

And now you’ve successfully updated trunk.

Top ↑

“Tagging” New Versions “Tagging” New Versions

プラグインの正式なリリースを行うたびに、そのリリースのコードのコピーをタグ付けする必要があります。これにより、ユーザーは簡単に最新版(または旧版)を手に入れることができ、変更点をより簡単に把握することができます。また、WordPress.org Plugin Directory は、あなたのプラグインのどのバージョンをダウンロードするように伝えるべきかを知ることができます。

Each time you make a formal release of your plugin, you should tag a copy of that release’s code. This lets your users easily grab the latest (or an older) version, it lets you keep track of changes more easily, and lets the WordPress.org Plugin Directory know what version of your plugin it should tell people to download.

まず、コードをtags/ディレクトリ内のサブディレクトリにコピーします。WordPress.orgのプラグインブラウザのために、新しいサブディレクトリは常に次のようなバージョン番号のようにする必要があります。2.0.1.3は良いです。Cool hotnessタグだめです。

First copy your code to a subdirectory in the tags/ directory. For the sake of the WordPress.org plugin browser, the new subdirectory should always look like a version number. 2.0.1.3 is good. Cool hotness tag is bad.

SVNの機能を活用するために、通常のcpの代わりにsvn cpを使用したいと思います。

We want to use svn cp instead of the regular cp in order to take advantage of SVN’s features.

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

いつものように、変更を確認してください。

As always, check in the changes.

1
2
3
4
5
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.txtStable Tagフィールドを新しいバージョンに更新することを忘れないでください。

When tagging a new version, remember to update the Stable Tag field in trunk/readme.txt to the new version.

おめでとうございます。これでコードが更新できました!

Congratulations! You’ve updated your code!

Top ↑

Notes Notes

あなたのプラグインを使用するすべての人に(不必要と思われる)、デプロイする意思と用意がないものは、SVN に置かないでください。これにはvendorファイル、.gitignore、その他すべてのものが含まれます。

Don’t put anything in SVN that you’re not willing and prepared to have deployed to everyone who uses your plugin. This includes vendor files, .gitignore and everything else.

また、zip ファイルのアップロードも絶対に避けてください。他のコードリポジトリシステムと同様に、SVN は個々のファイルをアップロードすることを想定しています。

You also should never upload zip files. Like most code repository systems, SVN expects you to upload individual files.

Top ↑

See Also See Also