Tera Term

svnがいいという意見もあるんじゃないかと考えると、1つのリポジトリでsvn
でもgitでも使えるのが理想ですけど難しいのかなと思います。
(できるのはgit-svnぐらい?)

以前にcsvからsvnに移行したように、そのうちgitに移行するのがよいなと思
います。(個人的にはgitにしようよ、です)

GitHubのPull Requestはとても魅力的で、
改善提案のハードルはかなり下がりそうですよね。
clone速いですし。

移行で気になるところは、コミットログ、
rXXXX が追跡できなくなるのでは?というところです。
svnからgitに移行した先輩プロジェクトがあれば
どんなふうに移行したのか知りたいと思いました。

他のプロジェクトメンバーの意見も聞きたいです。
ML内では1週間なんて短すぎるという意見が出たこともありますが、
とりあえず1週間程度待ってみましょう。

GitHubにプロジェクトのアカウントがあったはずなので調べておきます。

メッセージ #92679 への返信
>> 併記など)、メール,アカウントの置き換えもできるととってもよさそうです。
>> 可能でしょうか?

> SVN のログの場合は、コミット内容と別管理なので後で自由に書き換えられますが、
git の場合はコミットログも含めて、git ハッシュの情報の生成に使われるので
過去の revision に対応する git ハッシュを探し出したうえで、連鎖的に書き換えていく
必要があるので、実現可能性に関しては調査が必要と思います。

ログメッセージの書き換えができました。(--commit-interval 1 と --msg-filter というオプションを指定)

例えば https://github.com/m-tmatma/ttssh2-work/commit/4fc6b63b39dd6332e98fa9b03b926388b2852f46
で以下のところで

commitHashes:
* r10411: 58514a7

となっています。

58514a7 が https://github.com/m-tmatma/ttssh2-work/commit/58514a7356102777f2118137d4d4936ea707b4ee へのリンクになっています。
これは r10411 に対応する git のコミットになります。

メッセージ #92734 への返信
> メッセージ #92654 への返信
>
> メリットとデメリットを「OSDN 内で Git へ移行」と「GitHub へ移行」で分けて考えてみました。
> OSDN 内で Git へ移行
> a. メリット
> a-1. 依存関係があるけれどコミットを分けたい変更を、ローカルで複数のコミットにして一括で push できる（これだけなら git-svn でも可能）

svn でも feature ブランチの運用はできますが、
git だと基本的に feature ブランチを作って、push して、他の人に公開する準備が出来たら、
Pull Request を作ってマージするという流れになりますよね。

その際、他の人のレビューを通せるのと、CI やコードチェックツール等を自動で実行することにより、
コンパイルが通らないようなコードを本流に入れるのをある程度防げると思います。

> a-2. VCS を Git から使い始めて Subversion は使えない人が多い？Git のほうが新規コントリビューターのハードルが下がる？
> b. デメリット
> a-1. 数値がインクリメントする Subversion のリビジョンに比べて、ハッシュは特定のコミットを指したときにいつ頃のソースだとか、前後のコミットのハッシュが分かりづらい
>（心理的なもので慣れかもしれないが、エンバグしたコミットの特定でリビジョンの数字を動かして update していくことがある）

私も長いこと SVN を使ってきたので、 git になれるまでは時間がかかりました。

途中でデグレが発生した場合にどのレビジョンで不具合が発生したか特定するために
git bisect という仕組みがあります。

git に対して、git bisect を行うことを通知して、 問題があるリビジョンと
問題がないリビジョンの情報を与えることによりgit が 2分探索で、問題が
発生する最初のリビジョンを特定してくれるものです。

例えば svn の場合 r100 でバグがなくて r200 ではバグがあることが
分かっていてr125 からバグが混入した場合を考える場合、以下のように
リビジョン範囲を二分探索で特定していくと思います。

* r100 でバグがないことを確認
* r200 でバグがあることを確認

1. r150 でテスト → バグがある → r100 ～ r150 の間にバグがある
2. r125 でテスト → バグがある → r100 ～ r125 の間にバグがある
3. r113 でテスト → バグがない → r113 ～ r125 の間にバグがある。
4. r119 でテスト → バグがない → r119 ～ r125 の間にバグがある
5. r122 でテスト → バグがない → r122 ～ r125 の間にバグがある。
6. r123 でテスト → バグがない → r123 ～ r125 の間にバグがある。
7. r124 でテスト → バグがない → r125 が最初のバグバージョン

2 ** 7 = 128 なので 7 回で 100個のリビジョンを確認できます。

svn の場合、自分で二分探索の計算をする必要がありますが、
git の場合、git bisect コマンドがこの作業を代行してくれる。

git bisect start
git bisect good r100に相当するハッシュ
git bisect bad r200に相当するハッシュ

→ r150 に相当する revision がチェックアウトされる。
→ テストして NG なので git bisect bad を実行する。
→ r125 に相当する revision がチェックアウトされる。
→ テストして OK なので git bisect good を実行する。
...
→ これを繰り返していくと r125 に相当する revsion でバグが混入したと特定できる。

git bisect を実行するたびにあと何ステップ必要か教えてくれます。


git bisect start の時点で good revision と bad revision を与えてやるやり方とか複数の方法があります。
https://qiita.com/usamik26/items/cce867b3b139ea5568a6

また上記参考サイトに記載されている通り、バグがあるか確認する作業を
スクリプト化できれば git bisect コマンドに与えることにより、
チェックアウトして、テストを実行する手順を自動的に実行して、
revision の特定まで行うことができます。


> b-2. Subversion のリビジョンをソースや生成フォルダ名に取り込んでいる箇所の対応が必要

はい、そうですね。
代わりに git のリビジョンを参照するように書き換える必要がありますね。


> b-3. 既存のコミットログ中の Subversion リビジョン（rXXXXX）へのリンクが死ぬ（松尾さんが指摘済み）
>
> GitHub へ移行
> c. メリット
> c-1. プルリクが受けやすくなる
> c-2. CIツールが使いやすくなる？

はい、GitHub には GitHub Action という CI があり、同時ビルド数が 20 となっています。
GitHub の public リポジトリではタダでついてきます。

> d. デメリット
> d-1. OSDN のリポジトリ と GitHub のリポジトリ / OSDN の ticket と GitHub の issue /

> OSDN にはメーリングリスト

メーリングリストはないのですが、
Github Discussionsという機能はあります。
https://docs.github.com/ja/discussions

デフォルトでは有効ではないので、設定で有効にする必要があります。

ここのように掲示板みたいな感じで公開で議論できる場です。
ドラッグアンドドロップでファイルをアップロードすることもできます。

> wiki

GitHub にも wiki はあります。

> storage

storage というのはどういう用途で使用しますか?

https://osdn.net/projects/ttssh2/releases/ からリリースバイナリをダウンロードできるように
する機能のことでしょうか?


リリース版バイナリを公開する機能は GitHub にもあります。
https://docs.github.com/ja/repositories/releasing-projects-on-github/managing-releases-in-a-repository


それともコミット権限がない人が任意のファイルをアップロードする機能でしょうか?

GitHub のチケットや Pull Request に関連ファイルをアップロードさせることは可能です。
https://docs.github.com/ja/get-started/writing-on-github/working-with-advanced-formatting/attaching-files


> プロジェクトWebページ機能があり GitHub にはない。

対応する機能として GitHub Pages という機能があります。
https://docs.github.com/ja/pages/getting-started-with-github-pages/creating-a-github-pages-site

アカウント名.github.io という名前の git リポジトリを作ることにより、
その内容を公開することができます。

通常の git リポジトリと同様に fork すれば、コミット権限のない人でも、fork した自分の
リポジトリを編集して pull request を送ることで web サイトの誤植の修正や改善に
貢献することができます。


ただプロジェクトWebページ機能にある CGI は、GitHub Pages にはありません。
https://osdn.net/docs/ProjectWeb_Services


> どちらの何を使う / 何を使わない、またはこれは併用する、などを決める必要がある。併用したとして、
> プロジェクトのリソースが分散するので外部から分かりづらくならないか。

1. OSDN のデータはリードオンリーにして変更しない。トップページに GitHub に移行した旨案内する。
2. あるいは、OSDN のデータを完全に丸コピーして、GitHub Pages の機能を使って公開する、などが
考えられます。

私としては、
2 は手間がかかるので、1 がいいかと思っています。

GitHub 側に移行中、あるいは移行してまだ時間がたってない時期には
Google の検索等でOSDN 側のサイトが上位にかかるなど、紛らわしい時期はあるかと思いますが、

時間が経過して GitHub 側に新しいコンテンツが追加されるにしたがって時間とともに
GitHub 側のコンテンツが検索上位に上がるようになってくるので、紛らわしい状況は
時間の経過とともに解消していくかと思います。


> d-2. 既存のコミットログ中の ticket へのリンクが死ぬ（#XXXXX は GitHub の issue 番号として解釈される。
> GitHub のソースブラウザで見たときに、過去分は OSDN へのリンクにすることができるか）

変換の際にコミットログを書き換えることはできているので、#XXXXX を GitHub の issue 番号と
解釈されないものに置換することは可能です。(現状はリンクを追加する形ですが、 #XXXXX をリンクと
誤認しない形にすることは可能です)

> > ソース管理が複数サービスにまたがっていれば安心
> e. それは「共有リポジトリが OSDN と GitHub の両方にあって、どちらに push しても自動的に同期されて、
> ハッシュも含めて完全に同じ状態になる」ということですか？
> ログの変換が挟まるのでこれは無理そう？

『OSDNのメールが止まったとき、ソース管理が複数サービスにまたがっていれば安心だな』に関しては、
zmatsuo さんのコメントなので意味するところをはっきりわかっているわけではないですが、

OSDN がどの程度の頻度で止まるかは知らないですが、基本的に GitHub は安定しているので、
止まった時にどうするということはあまり想定しなくてもいい程度安定しています。

ただもし、かりに GitHub が止まってしまった場合でも、git なのでローカルにリポジトリが
あるのでローカルにコミットして、おいて、GitHub が復旧したときに push することは可能です。
SVN と異なり、コミットできないことはありません。

また git なので他の git のホスティングサービスにそのまま push することも可能です。

> f. または、どこかの Git リポジトリのミラーを GitHub がやっているのを見たことがありますが、「OSDN がマスターで GitHub はミラー」ということですか？
> OSDN が落ちている最中には GitHub をマスターとして利用して、復旧したら普段とは逆方向に同期してからマスターを入れ替えるようなことを想定していますか？
> g. それとも、GitHub 側がマスターですか？

私の提案は GitHub をマスターとして OSDN を使うにしても過去データを参照するだけの
読み込み専用とするイメージで考えています。

> コミットログの変換がテストされていますが、「おそらくコミットログを双方向に変換することはできない」
>「GitHub 側をミラーにするとしたら、GitHub へのプルリクを OSDN でマージするようなことはおそらくできない」
> ので、GitHub 側がマスターになるしかない？

これは ODSN の svn の話でしょうか?
svn に関しては GitHub に移行した場合は逆変換することはできない認識です。

OSDN のプルリクエストに関してはあまり知らないのですが、
GitHub とは互換性はないようです。

https://osdn.net/docs/PullRequest


> 提案をいただくのはありたがいですし自由ですが、運用方法を決めて実際にそれをずっと
> 継続していく（やめられなくなる）のはプロジェクトメンバーです。

メリットよりデメリットが大きいと判断されるのであれば、提案を採用しないというのは全然問題ないです。
懸念は少しは解消したでしょうか?
何かほかに懸念や心配はありますか?