今回のテーマは、古いSubversionからのバージョンアップについて。

(2020/6/19-1.7かそれ以前から、に修正し加筆)

前提

Subversion1.7 or olderから新しいバージョンへ

Subversion1.6

Subversion1.6は2009年8月にリリースされたもの。約１０年前、という事になる。Redhat Enterprise Linuxなどのパッケージに入ったのもあり、また多くの図面やデータ管理システムのバックエンドとして採用されたので、今でも使っている、というユーザは多い（お問合せのお客さまでも結構ある）。1.6シリーズはApacheでは既にメンテナンスを終了しているため、セキュリティリスクなどに対応するためには最新版に上げる必要がある。が、安定稼働している場合には躊躇もあるだろうと思われる。
通常バージョンアップのハードルは高くない。リポジトリは上位互換なので（テストはした方がいいが）そのまま使えるはず。OSのバージョンなども変わるのであれば、hookスクリプトは確認が必要だが。ただ、1.6からそれ以降へのバージョンアップには少し壁がある。

Subversion1.7ではクライアントのデータ構造が変更

Subversionはクライアント・サーバ型で動作するソフトウェアなので、クライアント側(PC側)にもデータを持つ。業務データ（ユーザのファイルなど）だけではなく、管理情報も保有しているのだが、Subversion1.7ではこのクライアント側のファイル構造が変更されている。したがって、何も考えずにクライアントソフト(TortoiseSVNなど)を上書きで1.7以降にバージョンアップすると、そのままでは動作しなくなってしまう。

さらにSubversion1.8でもクライアントのデータ構造が変更に（加筆）

1.8でさらに変更が入りました。同様にアップグレードが必要になります。1.8から加筆時点の最新の1.14までは変更ありません。

移行は２つの方法
(1) クライアント側でデータを変換する

まずクライアントバージョンアップの「前」に作業が必要。古いクライアント環境で、"svn cleanup"を全ての作業コピーに実行する。そして、バージョンアップ後に"svn upgrade"を行う。
svn cleanupは作業コピーに溜まった問題（参照関係の破壊とか）を修復してくれるのだが、修復しきれない事もある。そんな時は、バージョンアップ後のsvn upgradeもうまく行えないので、後述する「チェックアウトし直す」方法で行う事になる。svn cleanupをせずにバージョンアップしてしまった場合も同様。

(2) チェックアウトし直す

手持ちの作業コピーを放棄し、クライアントをバージョンアップした上でチェックアウトし直せば新しいフォーマットで保存される。作業中のファイルがあれば別フォルダに退避しておく。
ただ、移行前後に一斉にコミットしたりチェックアウトするとサーバの能力を超えてしまうことが懸念されるため、時差を設けるのがよいだろう。

作業お手伝いしています

弊社ではSubversionサーバの構築やサポートを行っています。ぜひお問い合わせください。