コラム
Subversion...
Subversion 1.10 リリースノート（アルファ）
ページ更新日：2020-06-17
「Apache Subveriosn 1.10リリースノート（アルファ）」
現在、Apache Foundationで開発が進められております、Apache Subvesrion 1.10のリリースノートの日本語翻訳を掲載します。なお本稿は「α版」時点の翻訳となっております。また、冗長な表現などは意訳しています。
（翻訳：Sayaka）
2018.7補足：Version1.6からの変遷と今後のリリースサイクルの変更も掲載しています。合わせてどうぞ。
Apache Subversion 1.10の新機能とは
・改善されたパスベースの認可
・新しいインタラクティブなコンフリクトリゾルバ
・LZ4 圧縮
・多くの機能拡張とバグ修正
・リリースの既知の課題
・このリリース固有の問題のトラブルシューティング
Apache Subversion 1.10はApache Subversion 1.10は以前のすべてのSubversionリリースのスーパーセットであり、現在の「ベスト」と見なされるリリースです。 1.0.x〜1.9.xの機能やバグフィックスも1.10に含まれています。また、1.10には以前のリリースにはない機能やバグフィックスが含まれています。新しい機能は、最終的に無料のSubversionブック（svnbook.red-bean.com）の1.10バージョンで文書化されます。
このページでは、大きな変更点についてのみ説明します。変更の完全なリストについては、CHANGESファイルの1.10セクションを参照してください。
コンパチビリティ(互換性)に関して
古いクライアントとサーバーは、1.10サーバーとクライアントと透過的に相互に情報通信が可能です。ただし、クライアントとサーバーの両方が最新バージョンでないと、新しい1.10機能の一部が使用できない場合があります。クライアントが新しくサーバーが古い場合は新しい動作は効率的に動作しないことがあります。
リポジトリをdump,reloadする必要はありません。 Subversion 1.10サーバーは、以前のバージョンで作成されたリポジトリに読み書きできます。既存のサーバーをアップグレードするには、最新のライブラリとバイナリを古いものに上書きしてください。
svnadmin createは、デフォルトで新しいfilesystem format 8を使用してリポジトリを作成することに注意してください。Subversion 1.10がGAになるまで、この新しいファイルシステム形式のリポジトリにはアップグレードパスは約束されません。したがって、長期間保存する予定のデータには、新しく作成したリポジトリを使用しないでください。詳細については、プレリリースに関するポリシーをご覧ください。
Subversion 1.10は、新しい機能を追加するだけで、古い機能を削除することなく、以前のリリースとのAPI / ABIの互換性を維持します。以前の1.x APIに書き込まれたプログラムは、1.10のライブラリを使用してコンパイルおよび実行できます。しかし、1.10用に書かれたプログラムは、古いライブラリに対してコンパイルあるいは実行できるとは限りません。
古いAPIの動作が以前のリリースから若干変更されたケースは限定されています。これらの機能がバグであるとみなされ、したがって改善または削除されたケースです。これらのAPIの内容と、これらの変更がもたらす影響についての詳細は、API erretaを参照してくださ
新機能のコンパチビリティテーブル
| 新機能 | 最小クライアント１ | 最小サーバー | 最小リポジトリ | ノート |
| Improved path-based authorization | any | 1.10 | any | Existing authz configurations may need to be adjusted. |
| New interactive conflict resolver | 1.10 | any | any | Use SVN 1.8 and above clients only for best results. |
| LZ4 compression over the wire in http:// connections | 1.10 | 1.10 | any | |
| LZ4 compression in the backend storage | any | any | 1.10 | FSFS only |
| 1Reminder: when using the file:// repository access method, the Subversion program is both the client and the server. | ||||
作業コピーのアップグレード
Subversion 1.10は、Subversion 1.8および1.9と同じ作業コピーフォーマットを使用します。
既存のSubversion 1.7以前の作業コピーでSubversion 1.10を使用する前に、作業コピーのメタデータを新しい形式にアップグレードするため、svn upgradeコマンドを実行する必要があります。このコマンドは、場合によってはしばらく時間がかかることがあり、ユーザーによっては、新しい作業コピーを単にチェックアウトするほうが実用的かもしれません。
注意： 1.6でsvn クリーンアップを事前に行わなかった為にアップグレードできなかった作業コピーを、Subversion 1.10ではアップグレードすることはできません。つまり、1.8以上にアップグレードする前に、1.6以前の古いクライアントを使用して、クリーンアップが必要なすべての1.6以前の作業コピーに対してsvn cleanupを実行する必要があります。同様に、Subversion 1.10は破損した作業コピーをアップグレードすることはできません。 .svnディレクトリ内のメタデータがないか破損しているため、修正不可能な問題が発生する可能性があります。このような作業コピーへのダメージは永続的であり、アップグレード前にsvnクリーンアップを実行しても修正できません。
作業コピーが正常にアップグレードされない場合は、新しいものをチェックアウトし直してください。
その他のコンパチビリティに関する注意事項
このリリースで行われた変更により、管理者またはユーザーによるさらなる調整が必要になる可能性のある特定の追加の領域がいくつかあります。このセクションではそれらについて説明します。
このリリースは1.10となります
"1.10.0"はASCII文字列と見なされると "1.9.0"よりも小さいと扱われるため、Subversionのバージョンを文字列として比較するスクリプトは、 "1.10.0"と "1.9.0"のどちらが新しいかを正しく判別できない場合があります。そのようなスクリプトは、Subversionのバージョン番号を正しく比較するように変更する必要があります：整数のタプル（組）に、開発用またはリリース前のバージョンのオプションの接尾辞がつきます。詳細については、Subversionリリース番号のドキュメントを参照してください。 （C APIまたはさまざまなバインディングに対して書かれたプログラムは、svn_version_ *.interfacesを参照する必要があります）。
svnadminサブコマンドは、ロックされたパスの出力方法が変更されました。
svnadmin lock、svnadmi unlock、およびsvnadmin rmlocksサブコマンドは、ロックされたパスを以前とは異なる方法で出力します。
1.9以前では、パスは入力された形式と全く同じに出力されます。 1.10では、パスは "canonical"形式で出力されます。ドットコンポーネント（foo /./ bar）は省略され、複数のスラッシュ（foo // bar）は1つに圧縮されています。入力の先頭にスラッシュがあるかどうかに関わらず、出力するパスはスラッシュで始まります。
例)
$ svnadmin-1.9 lock r //iota jrandom logmsg opaquelocktoken:42
'//iota' locked by user 'jrandom'.
$ svnadmin-1.9 unlock r //iota jrandom opaquelocktoken:42
'//iota' unlocked by user 'jrandom'.
$ svnadmin-1.10 lock r //iota jrandom logmsg opaquelocktoken:42
'/iota' locked by user 'jrandom'.
$ svnadmin-1.10 unlock r //iota jrandom opaquelocktoken:42
'/iota' unlocked by user 'jrandom'.
$
出力のみが変更されます。有効な入力のセットとそれらのsvnadminの動作は変更されていません。 svnadminは、コマンドライン引数として複数のスラッシュ、ドットコンポーネントなどの有無にかかわらずパスを受け入れ続けます。
SASLなしでビルドされた場合”svnserve”は”use-sasl = true”を検知しエラーにします。
Cyrus SASLトランスポートをサポートせずに構築されたsvnserveの動作が変更されました。
Subversion 1.9以前では、svnserveはSASLサポートなしでビルドされると、svnserve.confのuse-sasl設定を無視します。 Subversion 1.10では、SASLサポートなしでビルドされたsvnserveは、use-saslがtrueに設定されているとエラーになります。
それ以外はsvnserveの動作は変更されません。特に、SASLサポートありでビルドの動作は変更されていません。
API erratumを参照ください。
新機能
改善されたパスベースの認可
Subversion 1.10では、パフォーマンスとワイルドカードのサポートを改善した、パスベースの認証の新しい実装が提供されています。
既存の認可ルールには、リポジトリ固有のものとグローバルなものの2つがあります。
[repos:/path]
[/path]
これらのルールでは、/ pathは常に文字列としてマッチします。
新しい認可ルールパーサーは、パスエレメントにワイルドカードを含むルールの2つの新しい形式をサポートしています。
[:glob:repos:/path]
[:glob:/path]
globルールでは、次のワイルドカード・シレタックスがサポートされています。
*は、単一の（厳密に1つの）任意のパスセグメントにマッチします
**はスラッシュで区切られた任意の数のパスセグメントにマッチします。/
* foo * .barなどの古典的なワイルドカードパターンは、特殊文字をバックスラッシュでエスケープすることも含めて、期待通りに動作します。
全てのワイルドカードは、フルパス・セグメントのみに適用されます。例えば、/**/はゼロまたはそれ以上のパスセグメントにマッチする、という以外は * は、/ にはマッチしません。/*/**/* は、少なくとも2つのセグメントを持つ場合にマッチし、/**/*/* や /*/*/**と同値です。
グローバル・ルールでは、パスにワイルドカードを含む必要はなく、そのため、2つの異なった名前のセクションも、同じパスとして扱われます。次の2つのルールは同値です。
[/path/without/wildcards]
[:glob:/path/without/wildcards]
新しい認可ルールパーサーは次のようなコンフリクトを検出します。
Subversion1.9以前の古い認可パーサーでは、下記のようなWrite Only（書き込みのみ許可）というシンタックスを許可していました。
[/]
* = w
新しいパーサーでは、上記のような設定はエラーになります。ただ、実際には古いパーサーも新しいパーサーもWrite Onlyのアクセスはサポートしていません。
新しいインタラクティブなコンフリクトリゾルバ
新しいコンフリクトリゾルバは、リポジトリ履歴を検索して、作業コピーのローカル変更と競合し、ツリーのコンフリクトを引き起こす構造的な変更(additions , deletions , copies , moves)を探します。リビジョン番号や競合する変更の作成者の名前など、ツリーの競合について詳しく説明します。以前のバージョンのSubversionでは、そのような情報を見つけるタスクはユーザに任されていました。この作業を自動化することは、ユーザビリティの大幅な向上です。
新しいコンフリクトリゾルバは、リポジトリ履歴内の移動と名前の変更を検出し、ローカル作業コピーを変更する間にアカウントに入れることができます。これにより、もし一方または両方のブランチのファイルかディレクトリの名前が変更されても、ブランチ間のシームレスマージが可能になります。最良の結果を得るには、リポジトリにコミットするすべてのSVNクライアントがバージョン1.8以上である必要があります。
新しいコンフリクトリゾルバは、合理的な方法がひとつである場合はいつも、解決オプションについてユーザーに尋ねることはありません。たとえば、ファイルがリポジトリ内の別の場所に移動された場合、コンフリクトリゾルバは、必要に応じて同じ移動動作をローカルに実行することができ、ユーザーに代わってコンフリクトを解決しようとします。これにより、ユーザーは自動的に解決できないコンフリクトに集中することができます。
移動や名前の検出はヒューリスティックな部分があるため、検出は完璧ではなく、考えられるすべてのケースで機能するわけではありません。移動と名前の変更の取得の詳細については、 ”Subversionのコンフリクトリゾルバが移動を取得する方法 ”を参照してください。
コンフリクトリゾルバのユーザーインターフェイスはほとんど変わりません。以前のリリースと同様に、リゾルバは、update、merge、またはswitch操作が終了する際コンフリクトがあれば自動的に開始されます。また、svn resolveコマンドを実行することによってオンデマンドで起動することもできます。詳細については、Subversion 1.10のインストール後にsvn help resolveを実行してください。
状況によっては、1つのコンフリクトを解決すると、他の新しいコンフリクトが発生します。 svn resolveコマンドは、コンフリクトが全て解消するか、ユーザーが中断を決定するまで、このようなコンフリクト解消作業を繰り返し続けます。
新しいコンフリクトリゾルバは、svn resolve、SubversionのクライアントAPI（Cやその他の言語バインディング）、またはシェルスクリプトで使用する非対話型svnconflictツールと対話的に動くことができます。
新しいコンフリクトリゾルバでは、様々な自動コンフリクト解決のオプションを提供します。すべての種類のコンフリクトがまだ記述され解決されているわけではありません。 Subversion 1.10.0で利用可能なオプションを以下の表に示します。この表では、取得側およびローカル側の項目は、両方ともファイルまたは両方ともディレクトリのいずれかです。ファイルがディレクトリとコンフリクトするほとんどの場合は、まだハンドルされていません。
Subversionの今後のリリースでは、引き続き新しいコンフリクトリゾルバの拡張機能が提供されます。パッチのリリース（つまり、1.10.1,1.10.2など）であっても、です。
| local change | incoming change | operation | resolution options |
| • edit file • any change inside a directory |
• delete file / directory | update, switch, merge | • ignore deletion • accept deletion |
| • move file / directory | update, switch, merge | • move and merge (applies the same move locally and merges items) |
|
| • add item | • add item | update, switch | • ignore incoming addition
(discards the incoming change) • merge incoming and local item |
| merge | • ignore incoming addition
(discards the incoming change) • merge incoming and local item (item's log history will trace back on local branch) • replace local item with incoming item, then merge them (item's log history will trace back to other branch) |
||
| • move item | • edit file • any change inside directory |
update, switch | • apply change to move destination • break move and update any moved away children (updates items moved outside of the moved directory) |
| merge | • apply change to move destination | ||
| • delete item | • edit file • any change inside directory |
update, switch, merge | • keep working copy state (deleted file / directory), discarding incoming changes |
LZ4圧縮
Subversion 1.10では、以前のバージョンで使用されていたzlib圧縮に加えてLZ4圧縮がサポートされました。 LZ4は、圧縮率を維持しながら、高速で圧縮と解凍をすることができます。 LZ4圧縮を使用すると、圧縮可能な大容量のファイルを含む(又は、圧縮できないファイルを含む場合でもおそらく)リポジトリのほとんどのSubversion操作のパフォーマンスが大幅に向上します。
現在、mod_dav_svnにSVNCompressionLevel 1ディレクティブを設定することによって、http(s)://経由でSubversion 1.10クライアントに転送されるデータに対して、LZ4圧縮を有効にすることができます。これとは別に、fsfs.conf構成ファイルでcompression-level = 1を設定することにより、filesystem format 8（下記参照）の新しいリポジトリ内のオンディスクデータを有効にすることもできます。
ファイルシステムフォーマットバンプ
デフォルトのファイルシステムフォーマットは、file system format “8”になりました（svnadmin infoコマンドは、リポジトリのファイルシステムフォーマット番号を表示します）。
フォーマットバンプは、ディスク上のデータにLZ4圧縮を使用できるようにするために必要です。既存のデータにLZ4圧縮を使用するには、fsfs.conf構成ファイルで圧縮レベル= 1を設定した新しいリポジトリに完全な dump/loadサイクルを実行する必要があります。
警告：Subversion 1.10が一般的に利用可能になるまで、filesystem format 8のリポジトリのアップグレードパスは約束されません。本番環境で使用されている既存のリポジトリはアップグレードしないでください。また、維持する。詳細については、プレリリースに関するポリシーをご覧ください。
拡張機能とバグ修正
コマンドラインクライアントの改善(クライアント)
svn log --searchの改善
svn log --searchは大文字と小文字を区別しないようになりました。これにより、大文字と英語以外の文字を含むようになったパスとログメッセージを簡単に一致させることができます。
svnbenchの改善
svnbenchは実行時刻とネットワーク経由で転送された合計バイト数を表示するようになりました。Subversion 1.9で動作しなかった--with-no-revpropsオプションは修正されました。
サーバー側の改善
(新) svnadmin load に--no-flush-to-disk オプションが追加されました
svnadmin loadコマンドに新しい –no-flush-to-diskオプションが追加されました。このオプションを使用すると、結果として得られるデータがシステムのクラッシュや電力損失に耐えることを保証する必要がない場合に、ロードのプロセスを大幅に高速化することができます。例えば、ダンプファイルを新しいリポジトリにロードするときに使用します。
(新) svnadmin dump-revprops 、 svnadmin load-revprops サブコマンド
svnadminは、リポジトリに対する他の変更とは独立して、リビジョンのプロパティをダンプ/ロードできるようになりました。リビジョンプロパティのバージョン管理はされていませんが、管理者がリポジトリのpre-revprop-change hookを設定している場合、値が変更できるので便利です。
svnadmin dump-revpropsは、すべてのリビジョンプロパティの現在の値をダンプファイルに保存します。 svnadmin load-revpropsを使用すると、リポジトリのリビジョンプロパティをダンプファイルに保存された値に設定できます。
クライアント/サーバーの改善
RA-serfは、可能であればデルタ圧縮するようになりました
RA-serfは、 'http-compression = no'クライアント構成オプションによって圧縮が無効にされていない限り、可能であれば圧縮されたデルタ(差分)を送信するようになりました。これは、この特定の（新）機能のサポートをするサーバーで有効になります。 mod_dav_svnサーバは、この特定の（新しい）機能をサポートするようになりました。
Ref. r1704317, r1704891, r1791290.
リリースの既知の問題
Subversion 1.10リリースにはいくつかの既知の問題があります。これらは、後の1.10.xリリースで修正される予定です。
このリリース固有の問題のトラブルシューティング
Subversion 1.10では新機能が導入され、以前のバージョンでは発生しなかった問題を引き起こす可能性がある新しい技術が使用されています。既知の問題とは対照的に、ここに挙げたものは、Subversion自体のバグや問題によるものではないため、新しいパッチリリースで修正されることはありません。このセクションでは、すべての既知の問題をリストし、問題が発生した場合に解決するための手順を示します。
現時点でこのリリースに固有の既知の問題はありません。
Subversion 1.8.xシリーズのサポート終了
Subversion 1.8.xシリーズのメンテナンスは終了しますが、1.8がなくなるわけではありません。
お客様のシステム内で必要な作業に問題がなければそのまま使用が可能ですが、1.8.xのバグレポートの受付は終了し、バグフィックス版をリリースすることはもうありません。
Subversion...
