Trac/Subversion から GitHub への移行

[gocha]

HSPTV!掲示板 #95674 より、古くから使用されている Trac/Subversion/MantisBT のあたりを GitHub に移行したいと考えられてはいるものの、実現に至っていないものとお見受けします。HSPTV!掲示板 #97672 にも書き込みましたが、わたしも GitHub への移行を熱烈に歓迎するひとのひとりです。

それから、この onitama/OpenHSP リポジトリは Subversion とは別に時折コミットされているように見えますが、同期状態や運用ポリシーがよくわからず、疑問に思っています。 本リポジトリの現状の位置づけは HSP Linux/Raspberry Pi 向けであることを Subversion の package/linux/readme.txt より発見（以下引用）。

HSP Linux/Raspberry Pi
は、以下のリポジトリ管理に変更されました
https://github.com/onitama/OpenHSP

移行元

• Subversion http://dev.onionsoft.net/svn/openhsp/ (id: guest, password: guest)
• (任意) Wiki https://dev.onionsoft.net/trac/openhsp/wiki
• (任意) HSP3バグトラック http://dev.onionsoft.net/mantis/

移行にあたっての障害

移行にあたって、何が障害となっているのでしょうか？

掲示板の書き込みでは「今後はWindows版も含めた全般についてもgithubに統一する方向で考えています。(今までは文字コードの問題で統一できていませんでした)」と書かれており、ソースコード上の問題はもはや解消しているかのような印象を受けます。

移行に必要なタスク及びマイルストーン

移行には何が必要ですか？　以下は想像にもとづくものです。

• Subversion から Git への移行
  • 現存するこのリポジトリへの追加コミット? or git svn で Subversion のリポジトリをまるごと移行する
• HSP3バグトラッキングの移行 (任意)
  • 中に入れないので現状がわかりませんが、必要に応じて登録されている課題を手動で(?) GitHub に登録?
• Trac の Wiki の移行 (任意)
  • GitHub の Wiki に同じ内容を手動で移管?
• openhsp organization を作成?
• 既存の OpenHSP 開発者に周知を行い、古いサイトを読み取り専用にする
• Releases に過去の各種リリースを掲載する (任意)

[gocha]

本リポジトリの位置づけはよく理解できていないものの、そもそもディレクトリ構造も異なっていて、Subversion の複製ではないらしいことは理解。移行をするのであれば、Subversion から持ってきて不都合な点をいじりまわすほうがうまく行きそうかな？という感想。

追記: package/linux/readme.txt より以下を発見。

HSP Linux/Raspberry Pi
は、以下のリポジトリ管理に変更されました
https://github.com/onitama/OpenHSP

[gocha]

メモ: すでに https://github.com/zakki/openhsp にミラーが存在する。ただしブランチやタグの移植までは行われていない。

独自に git svn clone を使用した移行を実施中です。チェックアウト自体は小一時間で完了できるため、細かな整理を加えても順調に行けば一日以内に片付くと思います。

[gocha]

とりあえず Subversion のすべてのコミットを対象として Git リポジトリのクローンに成功しました。
openhsp-git-svn-1341.7z

これを git push しようとすると、100 MB を超えるファイルを持つコミットが存在することでエラーが発生します。
openhsp-git-push-logs.txt

remote: error: File hsp3dish/win32gp/gameplay/lib/gameplay.lib is 239.54 MB; this exceeds GitHub's file size limit of 100.00 MB
remote: error: File hsp3dish/win32gp/gameplay/lib/gameplay.lib is 257.67 MB; this exceeds GitHub's file size limit of 100.00 MB
remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.

remote: warning: File hsp3dish/gameplay/encoder/ipch/gameplay-encoder-5e40449c/gameplay-encoder-73487223.ipch is 78.75 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB
remote: warning: File package/linux/src/hsp3dish/gameplay/encoder/ipch/gameplay-encoder-5e40449c/gameplay-encoder-73487223.ipch is 88.39 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB
remote: warning: File package/win32/android/hspprojhg/app/libs/arm64-v8a/libgameplay.a is 50.02 MB; this is larger than GitHub's recommended maximum file size of 50.00 MB

これに対しては、2通りの解決策が考えられます。

• 巨大なファイルを Git LFS に移動する
  • git lfs migrate import で過去のコミットの書き換えも含めて Git LFS にファイルを移行できる
  • 問題点: 最小限を退避するだけでも、無料枠の 1 GB を超えてしまう
  • 参考情報: "Git LFS からファイルを削除した後でも、Git LFS オブジェクトはそのままリモートストレージに存在し、Git LFS ストレージ容量に対するカウントも継続します。Git LFS オブジェクトをリポジトリから削除するには、リポジトリを削除して再作成します。" とのこと https://docs.github.com/ja/repositories/working-with-files/managing-large-files/removing-files-from-git-large-file-storage
• 巨大ファイルをリポジトリから削除する
  • 問題点: そのファイルは完全に削除される

過去のコミットに含まれる巨大なバイナリファイルは、（別途安定リリース版のソースコードなどがアーカイブされているならば）削除されてもこれといって問題ないと個人的には思います。

とりあえず、バイナリファイルを歴史から消し去る方向でもうすこし進めてみようと思います。

[zakki]

私のミラーはbfgでの履歴書き換えで継続的にミラー更新するスクリプト書いてます。
https://gist.github.com/zakki/cd9ac2b41bbe4ec96015717d5b9078e1

[gocha]

とりあえず上記のファイルのみ bfg で削除したリポジトリを push しました。
それと、上記に掲載したアーカイブでは tags の付与位置が微妙だったので、手動で直しました。
（3.31@556 3.31 タグの親ツリーが他と異なっているけれど、rebase しようとするとバイナリ類が競合するのでその点は諦め）
https://github.com/gocha/openhsp

@zakki さんのスクリプトにある bfg のコマンドで削ったらさらにスリムになりそうですね。
どのくらいの弊害があるか私にはわからないので、とりあえず削っていないですが。

ご希望があれば、いつでもリポジトリの所有権を委譲します。

[onitama]

ご意見ありがとうございます。
OpenHSPのTrac/Svnは現状で履歴も含めて大変大きなデータになっており、すべてをgithubに持ってくるのは困難だと思っています。
githubのOpenHSPリポジトリは、現在はLinux/RaspberryPi版のパッケージ(SVNのtrunk/package/linux)として使用しています。
github移行のプランとしては、別途リポジトリを作成(たとえばOpenHSP3Baseなど)して、ソース部分のみ(SVNのtrunk/package,trunk/vendorを除いた部分)を持ってきてそちらをソースコードのマスターとする予定で考えています。ただ、現状ではpluginsなど一部のソースコードはまだUTF-8に移行されていないものがあります。
パッケージとしてのマスターは、画像やサウンド、バイナリ(実行ファイル)などのデータ類のみ従来のSvnで行うのが望ましいように思います。
何にしても、できる範囲でお手伝い頂くのは歓迎ですし、ご意見や報告なども見させて頂いています。
githubの方にWindows版のソースコードが同期できれば、GitHub Actionsなどで自動ビルドすることができるかもしれないので、β版やテスト等の利便性も上がると考えています。
バグトラックについても、登録など煩わしい部分があるのでgithubのIssuesに移行することが望ましいですが、現状では多くのご報告を掲示板で頂いているので、すぐにすべてを移行するという形は難しいように思います。

[gocha]

ご返信ありがとうございます。そして長年のHSPのメンテナンスお疲れ様です。本件の対応イメージや課題感がそれなりに理解できました。

HSP のソースコードにあまり理解がないのですが、主にサイズが大きいのは package (vendor も?) だと思いましたので、そこを除いてならサイズ問題はかなり抑えられそうですね。

掲示板と GitHub には異なるメリットとデメリットがあるため、どちらかの使用を辞める必要はないと個人的には思います。掲示板で報告を受けた不具合を随時 GitHub に転記するなど、そういった運用の仕方もありではないかと思います。

積極的に開発に携わる意欲があるわけでもないのに、いろいろ書いてしまって恐縮です。
現状、仮に何かをお手伝いしようと思っても、タスクや課題の一覧や状況を知ることが容易ではないと感じました。このようにオープンな場で課題別に情報を残そうとすることが、なにか似たような対応について考える方への参考などになれば幸いです。

管理上そうしたければ、この課題はクローズしていただいても構いません。ご回答ありがとうございました。