Forums: Open Discussion (Thread #47535)

git への移行 (2022-11-20 16:42 by m-tmatma #92629)

git へ移行しませんか?

https://ja.osdn.net/projects/ttssh2/forums/5840/41757/

で git への移行に関して、質問がありましたが、
git-svn を使う旨回答されて終了になっていました。

以下で svn-all-fast-export を使って svn を移行するスクリプトを書いてみました。
https://github.com/m-tmatma/ttssh2migrate

https://github.com/m-tmatma/ttssh2migrate/actions から artifact をダウンロードすることで
変換した Git リポジトリをダウンロードできます。

上記で変換したものを
https://github.com/m-tmatma/ttssh2-work
に push しています。

OSDN でも Git が使えるみたいですが、

GitHub Actions が利用できるので、GitHub に移行していただけるとありがたいです。

ご検討よろしくお願いします。




Re: git への移行 (2022-11-22 00:52 by zmatsuo #92654)

私自身はgit(git-svn)を使用しています。

git-svnについて次のページを参考にしてください。
https://ja.osdn.net/projects/ttssh2/wiki/repository

手もとのソースツリーからは、プライベートなgitリポジトリとプロジェクト
のsvnの2つのリモートを参照しています。

リモートgitリポジトリ(GitHub)をもう一つ追加してgitとsvnを相互にミラー
する、というのを試験的にやってみるのはどうだろうと考えていました。

でも、相互にコピーするのを手作業でやると何かミスしそうだし、何かツール
があればいいのにな、あるんじゃないかなと思っていました。

svn-all-fast-export は多分svnからgitリポジトリの一方通行のツールなのか
なと思います。gitリポジトリを作成するのにまずはこのツールを使うのはよ
さそうです。ツールでログ内のr9999などをgitのハッシュに置き換え(または
併記など)、メール,アカウントの置き換えもできるととってもよさそうです。
可能でしょうか?

8分ぐらいで変換できるんですね(git-svnだと上記ページを作ったときで20時
間でした)。

一気にgitに切り替えるのは管理上楽そうですが、svnのほうが良いと思われて
いる方もいらっしゃるかもしれませんし、GitHubをよく思わない方もいらっしゃ
るかもしれません。ドキュメントに切り替えなど時間が必要な部分もあるかも
しれません。svnとgitが同期しながら両方使えるのが便利だなと思います。

OSDNのメールが止まったとき、ソース管理が複数サービスにまたがっていれば
安心だなと感じたのも思い出しました。

意見をいただければと思います。
Reply to #92629

Re: git への移行 (2022-11-23 19:17 by m-tmatma #92679)

> git-svnについて次のページを参考にしてください。

SVN のレイアウト変更のあった r3221 移行を指定して実行してみましたが、
再度全リビジョンを指定して実行中です。

> 一気にgitに切り替えるのは管理上楽そうですが、svnのほうが良いと思われて
> いる方もいらっしゃるかもしれませんし、GitHubをよく思わない方もいらっしゃ
> るかもしれません。ドキュメントに切り替えなど時間が必要な部分もあるかも
> しれません。svnとgitが同期しながら両方使えるのが便利だなと思います。

zmatsuo さん自身は git に完全移行するのではなく svnとgit の併用したいでしょうか?

あるいは、技術的な問題や作業の手間的な問題が解消するのであれば移行したいと
考えておられますか?

今回提案させていただいたのは、コミット権限のない外部の人が簡単に Pull Request を
送って機能改善提案をできるようにしたいと思ったからです。

またGitHub Actions などの CI を使ってビルドが通ることを事前に確認したり
他の連携アプリなどを使用して問題のあるコードを自動検出したりできるようにもできたらと思います。

現状の運用では、コミット権限のない外部の人が貢献したいときに非常にハードルが
高いのかと思います。

ただそうは言っても、コミット履歴を見る限りアクティブに活動される方が
ほかにほぼいない状況では git に完全移行するのも難しいかもしれませんね。

> svn-all-fast-export は多分svnからgitリポジトリの一方通行のツールなのか
> なと思います。gitリポジトリを作成するのにまずはこのツールを使うのはよ
> さそうです。ツールでログ内のr9999などをgitのハッシュに置き換え(または
> 併記など)、メール,アカウントの置き換えもできるととってもよさそうです。
> 可能でしょうか?

アカウント情報とメールアドレスの対応関係の情報をいただければその情報を
引き継ぐことは可能です。(csv でその情報を与えると引き継げるようにはしました。)

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

例えば、 r9999 を https://osdn.net/projects/ttssh2/scm/svn/commits/9999
いうような URL に書き換えることは可能と思います。

ただ、実験的に行ってみたのですが、URL の一部に rXXX という形式のデータが
含まれる場合や、一行に複数のリビジョンが含まれる場合、1行が長くなりすぎる
とか実際にやる場合、適切な結果になるように調整は必要になるかとは思います。
Reply to #92654

Re: git への移行 (2022-11-25 23:43 by zmatsuo #92717)

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

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

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

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

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

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

Re: git への移行 (2022-11-26 06:59 by m-tmatma #92718)

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

git-svn で変換してみました。

r3221 でリポジトリレイアウト変更がありましたが、
それより前のリビジョンをうまく扱えないみたいですね。
(TortoiseGit のリビジョングラフで確認)

変換の時間が長すぎて、git-svn による変換を外部の開発者がやるのはなかなかしんどいです。

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

sakura-editor も svn から git に移行したのですが、(GitHub に移行してから少し開発に参加してたのですが)
sakura-editor ではコミットログを見る限り git-svn を使用したみたいです。

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

はい。
Reply to #92717

Re: git への移行 (2022-11-27 15:53 by m-tmatma #92729)

メッセージ #92717 への返信
> 移行で気になるところは、コミットログ、
> rXXXX が追跡できなくなるのでは?というところです。

https://osdn.net/projects/ttssh2/scm/svn/commits/10366 のコミットメッセージを
https://github.com/m-tmatma/ttssh2-work/commit/0b434640870f39e19aa783dc0727129f7ecdd512 のように変換してみました。
元の revision の URL および Issue のリンクを追加しています。

svn path=/trunk/; revision=10366 の部分は、svn-all-fast-export が変換時に自動付与します。

-----------------------------------------------------------------------------------------------
commit 0b434640870f39e19aa783dc0727129f7ecdd512
Author: zmatsuo <zmatsuo@example.com>
Date: Tue Nov 15 13:48:37 2022 +0000

Fix typo

- libs/ でcmakeビルド時にエラーとなっていた
- r10359

tickt #46066

Revisions:
* https://osdn.net/projects/ttssh2/scm/svn/commits/10359

Issues:
* https://osdn.net/projects/ttssh2/ticket/46066

svn path=/trunk/; revision=10366
-----------------------------------------------------------------------------------------------
Reply to #92717

Re: git への移行 (2022-11-29 23:10 by zmatsuo #92786)

sakura-editor 212de80 あたりでgitに切り替わったようですね。
https://github.com/sakura-editor/sakura/tree/212de8057e8d8fea780d657fe98eb0974303b440

> 過去の revision に対応する git ハッシュを探し出したうえで、連鎖的に書き換えていく
> 必要があるので、実現可能性に関しては調査が必要と思います。
ログに出てくる rXXXX は過去のはずなので
ハッシュはいつも参照できて、連鎖的書き換えにはならないんじゃないのかな。
(変換の中を見ずに予想で言っています。)

git-svn にはログの rXXXX を自動で置き換えたり
対応するハッシュを入れたりする機能はないようですね。

先輩プロジェクトは参照をあきらめてるのだろうか…。
Reply to #92729

Re: git への移行 (2022-11-27 19:06 by nmaya #92734)

メッセージ #92654 への返信

メリットとデメリットを「OSDN 内で Git へ移行」と「GitHub へ移行」で分けて考えてみました。

OSDN 内で Git へ移行
a. メリット
a-1. 依存関係があるけれどコミットを分けたい変更を、ローカルで複数のコミットにして一括で push できる(これだけなら git-svn でも可能)
a-2. VCS を Git から使い始めて Subversion は使えない人が多い?Git のほうが新規コントリビューターのハードルが下がる?
b. デメリット
a-1. 数値がインクリメントする Subversion のリビジョンに比べて、ハッシュは特定のコミットを指したときにいつ頃のソースだとか、前後のコミットのハッシュが分かりづらい(心理的なもので慣れかもしれないが、エンバグしたコミットの特定でリビジョンの数字を動かして update していくことがある)
b-2. Subversion のリビジョンをソースや生成フォルダ名に取り込んでいる箇所の対応が必要
b-3. 既存のコミットログ中の Subversion リビジョン(rXXXXX)へのリンクが死ぬ(松尾さんが指摘済み)

GitHub へ移行
c. メリット
c-1. プルリクが受けやすくなる
c-2. CIツールが使いやすくなる?
d. デメリット
d-1. OSDN のリポジトリ と GitHub のリポジトリ / OSDN の ticket と GitHub の issue / OSDN にはメーリングリスト・wiki・storage・プロジェクトWebページ機能があり GitHub にはない。どちらの何を使う / 何を使わない、またはこれは併用する、などを決める必要がある。併用したとして、プロジェクトのリソースが分散するので外部から分かりづらくならないか。
d-2. 既存のコミットログ中の ticket へのリンクが死ぬ(#XXXXX は GitHub の issue 番号として解釈される。GitHub のソースブラウザで見たときに、過去分は OSDN へのリンクにすることができるか)

> ソース管理が複数サービスにまたがっていれば安心
e. それは「共有リポジトリが OSDN と GitHub の両方にあって、どちらに push しても自動的に同期されて、ハッシュも含めて完全に同じ状態になる」ということですか?
ログの変換が挟まるのでこれは無理そう?
f. または、どこかの Git リポジトリのミラーを GitHub がやっているのを見たことがありますが、「OSDN がマスターで GitHub はミラー」ということですか?
OSDN が落ちている最中には GitHub をマスターとして利用して、復旧したら普段とは逆方向に同期してからマスターを入れ替えるようなことを想定していますか?
g. それとも、GitHub 側がマスターですか?
コミットログの変換がテストされていますが、「おそらくコミットログを双方向に変換することはできない」「GitHub 側をミラーにするとしたら、GitHub へのプルリクを OSDN でマージするようなことはおそらくできない」ので、GitHub 側がマスターになるしかない?

提案をいただくのはありたがいですし自由ですが、運用方法を決めて実際にそれをずっと継続していく(やめられなくなる)のはプロジェクトメンバーです。上記のようなことは、技術的に可能、かつ現実的に運用可能ですか?
Reply to #92654

Re: git への移行 (2022-11-29 22:27 by m-tmatma #92783)

メッセージ #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


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

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

Re: git への移行 (2022-11-30 22:42 by zmatsuo #92800)

subversionとgitの相互にミラーするツールを見つけました。
https://subgit.com/
でもsubversionとgitに同時にコミットされたときに
手作業で復旧する必要があるんだろうなと思うと
リポジトリは1つのほうがいろいろ手間がなくてよいですね。

OSDNでもPull Requestが使えるんですね
GitHubがよく使われているのでそちらのほうがいいのかな

と言いつつも私がGitHubのorganization使い方がわかっていませんでした。
https://github.com/TeraTermProject
ここに名前があってもつかえないですよね・・
https://github.com/orgs/TeraTermProject/followers

svnのリビジョンのような値としてコミット数が使えそうです。
バージョン番号に"ハッシュ.コミット数"みたいにするとかでしょうか。
Reply to #92783

Re: git への移行 (2022-12-01 12:34 by m-tmatma #92805)

メッセージ #92800 への返信
> subversionとgitの相互にミラーするツールを見つけました。
> https://subgit.com/
> でもsubversionとgitに同時にコミットされたときに
> 手作業で復旧する必要があるんだろうなと思うと
> リポジトリは1つのほうがいろいろ手間がなくてよいですね。

そうですね。

> OSDNでもPull Requestが使えるんですね
> GitHubがよく使われているのでそちらのほうがいいのかな

はい、GitHub に抵抗がある人がいるのも事実ですが、
最近は、GitHub の入門書も結構出版されてきているので
GitHub のほうが、新規参入者が見込めるかと思います。

> と言いつつも私がGitHubのorganization使い方がわかっていませんでした。
> https://github.com/TeraTermProject
> ここに名前があってもつかえないですよね・・
> https://github.com/orgs/TeraTermProject/followers

この followers はこの organization による活動をモニターしたい人がリストアップされるだけです。
私も試しに follow してみましたが、単に通知が来るようになるだけです。

この TeraTermProject の organization はどなたが作成されたものでしょうか?
それともプロジェクト外の方が作成されたものでしょうか?

organization のメンバーであれば、誰が owner であるか確認できるはずです。


> svnのリビジョンのような値としてコミット数が使えそうです。
> バージョン番号に"ハッシュ.コミット数"みたいにするとかでしょうか。

git には git describe というコマンドがあります。
https://kledgeb.blogspot.com/2015/11/git-437-git-describe.html

直近のタグからのコミット数 + コミットハッシュ
という形の文字列を生成することができます。

コミットされてない修正がある場合にわかるようにする `--dirty` というオプションもあります。





Reply to #92800