もとのバージョンはGitBucket 3.7、これを4.32.0に上げようと思いました。理由は、最近「git cloneが猛烈に遅い病」にかかっていることが判明して色々と調べたところ、どうもGitBucket自体が怪しいということになり、アップデートする決意をしました。
git cloneが遅くなる現象は、ネットでいくつか質問サイトに上がっていました。大体の回答は、大きなファイルをpushしたんだろう、とか、git fsck/git gcしたりしてリポジトリを整理したらというアドバイスが多かったように思いますが、スッキリそれで直ったという回答はあまり無かったように思います。実際、fsck/gcで改善しなかったし、大きなファイルもpushしていない、リポジトリサイズもそんなに大きくないので、当てはまる感じはしなかったです。
結局、
- どのクライアントからgit cloneしても猛烈に遅いこと
- GitBucketがホストしているすべてのリポジトリで同様であること
- GitBucketを通さずにgitサーバPC上のベアリポジトリを直接ファイルシステムからcloneすると問題ないこと
で、アップデートの方法ですが、GitBucketを停止して、gitbucket.warファイルを入れ替えれば済むものと思っていたけれど甘かった。3.x系から4.x系に上げるには、3.x系の最終版である3.14へのバージョンアップを経由してから、4.0に上げないといけないらしいということは検索で早めに調べがついていました。
3.7→3.14への移行方法：
ここでは、かなりの試行錯誤が必要でした。結果的にうまく言った方法は次のようなものでした。
- 使っていた3.7のデータベースを、H2にてSQLファイルにエクスポート（バックアップ）
- まっさらの状態でGitBucket 3.14を起動して、H2 ConsoleからエクスポートしたSQLファイルを実行して読み込み。
- 上記２で生成されたdata.mv.dbファイルに入れ替えてから、再度3.14を起動。
これで、3.7のときのユーザー設定やリポジトリ設定が3.14に移行できました。
1.のエクスポートは、GitBucket 3.7のWEB-UIが起動しなかったので、たけぞうさんの指示通り、直接データベースから引き抜きました。
なお、h2-1.4.xxxx.jarファイルは、tmpディレクトリにあるものを使いました。tmpディレクトリは c:\Users\(ユーザー名)\.gitbucket\ にあるもので、gitbucket.warを起動したときに展開される中身（jarライブラリ）のようです。
また、2.のSQLファイル実行は、GitBucket内のH2 Consoleから、次のように入力しました。
SQLの結果は、デフォルトの接続先DBである、~/test.mv.dbに出力されていました。
3.14→4.0への移行方法：
これは、単純にgitbucket.warファイルの入れ替えだけで、データベースをうまくアップグレードしてくれました。要は、GitBucketを停止させてから、gitbucket.warファイルを更新し、再起動するだけです。
4.0→4.32への移行方法：
上と同じように、gitbucket.warファイルを入れ替えるだけで良かったのですが、いきなりバージョンを上げるとエラーが出ることが多かったです。4.0→4.1→4.2→・・・とチマチマ上げていかないと、起動時にエラーが出ました。そして、エラーが出るとデータベース
ファイルが更新されているのか、元のバージョンに戻してもエラーが出続けることがありました。つまり、うまくいったらデータベースのバックアップを取っておかないと、最初からやり直しになることがありました。
とはいえ、すべてのリリースバージョンを１つ１つ実行しないといけないわけでも無いようです。２～３つ飛ばしても、エラーは出ずにうまくデータベースを更新する時もありました。
ここまで細かくきざむ必要はなかったかも知れませんが、覚えている範囲では次のようなバージョンステップを踏みました。
4.0→4.1→4.2.1→4.3→4.5→4.6→4.7.1→4.8→4.9→4.10→4.11→4.12.1→4.13→4.14.1→4.15.0→4.19.3→4.20.0→4.25.0→4.26.0→4.27.0→4.28.0→4.29.0→4.30.0→4.31.0→4.32.0
これで、3.7のときの各種設定のまま、4.32.0に移行できました。ここまで約１日半くらいかかっていました。
ようやく、元の問題である「git clone超スロー病」が解決したかどうか試すことができる段階になったのですが、時間切れとなりましたので、それはまた別の日に。