Foros: 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のメールが止まったとき、ソース管理が複数サービスにまたがっていれば
安心だなと感じたのも思い出しました。

意見をいただければと思います。
Responder al #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行が長くなりすぎる
とか実際にやる場合、適切な結果になるように調整は必要になるかとは思います。
Responder al #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にプロジェクトのアカウントがあったはずなので調べておきます。
Responder al #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週間程度待ってみましょう。

はい。
Responder al #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
-----------------------------------------------------------------------------------------------
Responder al #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 を自動で置き換えたり
対応するハッシュを入れたりする機能はないようですね。

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

Re: git への移行 (2022-12-02 23:11 by m-tmatma #92832)

メッセージ #92786 への返信
> sakura-editor 212de80 あたりでgitに切り替わったようですね。
> https://github.com/sakura-editor/sakura/tree/212de8057e8d8fea780d657fe98eb0974303b440
>
> > 過去の revision に対応する git ハッシュを探し出したうえで、連鎖的に書き換えていく
> > 必要があるので、実現可能性に関しては調査が必要と思います。
> ログに出てくる rXXXX は過去のはずなので
> ハッシュはいつも参照できて、連鎖的書き換えにはならないんじゃないのかな。
> (変換の中を見ずに予想で言っています。)
>


このメッセージ見逃してました。

前提として、既存ツールでコミットログの中の svn ログを解析して
それを git のハッシュとして展開する機能を持っているツールがない
というものがあります。

その前提の上で、それをやろうとすると自前でログ書き換えをする必要があります。
そうなった場合、すでに commit hash が確定している状態で書き換えるので連鎖書き換えが
必要になります。


ツールで対応している場合は、連鎖書き換えにはならない可能性は高いと思います。

> git-svn にはログの rXXXX を自動で置き換えたり
> 対応するハッシュを入れたりする機能はないようですね。
>
> 先輩プロジェクトは参照をあきらめてるのだろうか…。


git ではそもそも commit hash を直接言及することが少ないという事情があるかと思います。

git では feature ブランチを作って、push して pull request を投げてマージします。
後で参照する場合は commit hash を参照するのではなく pull request の番号を参照します。

複数の commit で一つの対応になるのが当たり前というのもありますが、
git の場合、 rebase という機能があり既存の commit を書き換える可能があります。

commit の順番を変えたり、なかったことにしたり、2 つ以上のcommit をくっけたり
することができます。

rebase すると commit hash が変化するので、commit hash を直接人が参照することに
意味がなくなってしまいます。

OSS を fork して pull request を送った場合に、OSS 本体で修正が入った場合
pull request が古くなって、OSS 本体側の修正を取り込む必要がある場合があります。

この場合 svn だと OSS本体側 (trunk) の修正を自分の feature ブランチにマージすることになりますが、

git の場合 rebase するという選択肢をとることが多いです。

これは 古いベースの trunk に対して行った修正を、更新された trunk に対して行ったかのように自分の commit を書き換える機能です。

履歴を一直線にしてきれいにすることで、自分の貢献が何かわかりやすくすることができます。
もし rebase しない場合、本領のマージコミットが大量に入って本質的な修正が何かレビューアーにとってわかりにくくなるため
git を採用してる OSS では rebase しておくことがマナーとされます。

慣れるまでは時間がかかりますが。
Responder al #92786

Re: git への移行 (2022-12-06 00:45 by zmatsuo #92855)

> git ではそもそも commit hash を直接言及することが少ないという事情があるかと思います。

hashをみてもぱっとわからないですよね。確かに変化してしまいますし。

大抵のリポジトリで
"This reverts commit ...hash..." というログはあると思います。
masterより前を参照するときならhashを付けるかな。

Tera Termのsvnリポジトリだと、
"r1234 のxxを修正した" とログにリビジョンを書いているので
これがgitのhashになれば便利かなと思っていました。

自分のgit-svnリポジトリの使い方を考えてみると、
r1234を調べたかったら、1234(svnのリビジョン)をログから検索して
git-svn-id: にマッチさせて参照していました。
git-svn-id があればおおむねokなのかな?

svnから持ってきたところ(git的にはmasterよりも前)は、
hashが変化してしまうような履歴の変更は
しないんじゃないかなと思います。
Responder al #92832

Re: git への移行 (2022-12-06 07:47 by m-tmatma #92860)

メッセージ #92855 への返信
> 大抵のリポジトリで
> "This reverts commit ...hash..." というログはあると思います。

これは git revert コマンドを実行すると自動的に生成するメッセージです。
開発者が手で入力しているわけではないです。

> Tera Termのsvnリポジトリだと、
> "r1234 のxxを修正した" とログにリビジョンを書いているので
> これがgitのhashになれば便利かなと思っていました。
>
> 自分のgit-svnリポジトリの使い方を考えてみると、
> r1234を調べたかったら、1234(svnのリビジョン)をログから検索して
> git-svn-id: にマッチさせて参照していました。
> git-svn-id があればおおむねokなのかな?

他のプロジェクトではそれでよしとしているように思います。

> svnから持ってきたところ(git的にはmasterよりも前)は、
> hashが変化してしまうような履歴の変更は
> しないんじゃないかなと思います。

はい、そうです。
ただその変換を行ってくれるツールが現状ありません。


Responder al #92855

Re: git への移行 (2022-12-26 07:43 by m-tmatma #93115)

メッセージ #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 のコミットになります。



Responder al #92679

Re: git への移行 (2022-12-26 09:53 by m-tmatma #93116)

メッセージ #93115 への返信
> メッセージ #92679 への返信

> 例えば https://github.com/m-tmatma/ttssh2-work/commit/4fc6b63b39dd6332e98fa9b03b926388b2852f46
> で以下のところで
>
> commitHashes:
> * r10411: 58514a7
>
> となっています。
>
上記で r10418 がリンクになってない件に関しては、未調査です。

Responder al #93115

Re: git への移行 (2022-12-27 21:17 by m-tmatma #93134)

メッセージ #93116 への返信
> メッセージ #93115 への返信
> > メッセージ #92679 への返信
>
> > 例えば https://github.com/m-tmatma/ttssh2-work/commit/4fc6b63b39dd6332e98fa9b03b926388b2852f46
> > で以下のところで
> >
> > commitHashes:
> > * r10411: 58514a7
> >
> > となっています。
> >
> 上記で r10418 がリンクになってない件に関しては、未調査です。
>

修正できました。
ログを修正したのでハッシュが変更になります。
https://github.com/m-tmatma/ttssh2-work/commit/98777409ab1b53d0b7afcbb5827d7e227eba93dc

Responder al #93116

Re: git への移行 (2022-12-30 02:19 by zmatsuo #93161)

👍
Responder al #93134

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 側がマスターになるしかない?

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


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

メリットよりデメリットが大きいと判断されるのであれば、提案を採用しないというのは全然問題ないです。
懸念は少しは解消したでしょうか?
何かほかに懸念や心配はありますか?
Responder al #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のリビジョンのような値としてコミット数が使えそうです。
バージョン番号に"ハッシュ.コミット数"みたいにするとかでしょうか。
Responder al #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` というオプションもあります。





Responder al #92800

Re: git への移行 (2022-12-03 19:35 by m-tmatma #92835)

メッセージ #92805 への返信
> > と言いつつも私がGitHubのorganization使い方がわかっていませんでした。

何ができるか実験するだけなら、自分用に適当な名前でテスト的に organization を作って何ができるか確認できます。
不要になれば削除もできますし、実験用にそのまま置いておくこともできます。

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

以下に書いていますが、Organizationのオーナーは複数人を割り当てることができます。(したほうがいいです)
https://docs.github.com/ja/organizations/managing-peoples-access-to-your-organization-with-roles/maintaining-ownership-continuity-for-your-organization

github では複数のロールを割り当てて使い分けることができます。
https://docs.github.com/ja/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization

Responder al #92805

Re: git への移行 (2022-12-06 00:53 by zmatsuo #92856)

そろそろ1週間たちました。

肯定的否定的というより、
~~どうかな、できるのかなという印象だと感じました。

移行するかどうかの前に
テスト的にGitHubにリポジトリのミラー(仮)を作って
GitHubのgitリポジトリをメインにメンバーで試しに使ってみては
どうだろうと思いますがいかがでしょう?

このgitミラー(仮)はコミットしたりforkしたりしてもよいが
やっぱりやめることになるかもしれないサンドボックス的な
リポジトリ-という位置づけで、
OSDNのsvnリポジトリは従来通り正です。
これでログの調整とかテストとか見ていくのはどうでしょうか。

まずその前段階で、私の中で
GitHub の Organization を把握しなければという状態です。
chocolatey-package リポジトリもありますし。

もう少々お時間ください。
Responder al #92835

Re: git への移行 (2022-12-06 07:35 by m-tmatma #92859)

メッセージ #92856 への返信
> そろそろ1週間たちました。
> 移行するかどうかの前に
> テスト的にGitHubにリポジトリのミラー(仮)を作って
> GitHubのgitリポジトリをメインにメンバーで試しに使ってみては
> どうだろうと思いますがいかがでしょう?

はい

> このgitミラー(仮)はコミットしたりforkしたりしてもよいが
> やっぱりやめることになるかもしれないサンドボックス的な
> リポジトリ-という位置づけで、
> OSDNのsvnリポジトリは従来通り正です。
> これでログの調整とかテストとか見ていくのはどうでしょうか。

https://github.com/m-tmatma/ttssh2migrate
を fork していただければ、ログの調整等は
自由に行っていただけます。

なお、GitHub Actions でビルドするのは私のほうでも以下で実験しています。
https://github.com/m-tmatma/ttssh2-work2

ただ cygwin のインストールのところで詰まっていてまだビルドに成功していません。

> まずその前段階で、私の中で
> GitHub の Organization を把握しなければという状態です。
> chocolatey-package リポジトリもありますし。
>
> もう少々お時間ください。

はい
Responder al #92856

Re: git への移行 (2022-12-06 21:54 by nmaya #92870)

メッセージ #92783 への返信

> svn でも feature ブランチの運用はできますが、
> git だと基本的に feature ブランチを作って、push して、他の人に公開する準備が出来たら、
> Pull Request を作ってマージするという流れになりますよね。
> その際、他の人のレビューを通せるのと、CI やコードチェックツール等を自動で実行することにより、
> コンパイルが通らないようなコードを本流に入れるのをある程度防げると思います。
いまの Tera Term プロジェクトには、すべての変更にレビューを通せるだけのリソースはありません。
コミットして、誰かに見てもらいたくてお願いしても、なんの返信もなくそのままになることも多々あります。(その場合は、それがそのまま生きになります)

> git bisect という仕組みがあります。
なるほど、これは知りませんでした。
マージしてから

> GitHub にも wiki はあります。
自分のリポジトリで表示されなかったので、無いものと思いました。有効にすればいいんですね。

> storage というのはどういう用途で使用しますか?
手元でビルドしたスナップショットや、その他の何かを置くことがあります。
https://osdn.net/projects/ttssh2/storage/snapshot/
https://osdn.net/projects/ttssh2/storage/tmp/20220914_zmatuso/
storage は issue などへの添付で代用できるように思えます。

> アカウント名.github.io という名前の git リポジトリを作ることにより、その内容を公開することができます。
それは、過去のドキュメントにも載っている https://ttssh2.osdn.jp という公式サイトを引っ越す、という意味になります。

> 時間の経過とともに解消していくかと思います。
今の公式サイトも、寺西さんのホームページ(https://hp.vector.co.jp/authors/VA002416/)のほうが上位にいた期間がかなりあったそうです。「OSDN はアーカイブにする」と決定したとして、どうアナウンスするかですね。
また、検索エンジンの下位だとしても、ここ(https://osdn.net/projects/ttssh2/releases/)に来れば「ずっと更新されていないリリースたち」という状態になります。
さらに、ここ(https://ttssh2.osdn.jp/manual/4/ja/)にマニュアルを checkout していて、多くの参照があると思われます。引っ越し後にここを放置すると「ずっと古い情報のまま」になります。
Responder al #92783

Re: git への移行 (2022-12-08 07:45 by m-tmatma #92894)

メッセージ #92870 への返信
> メッセージ #92783 への返信
>
> > svn でも feature ブランチの運用はできますが、
> > git だと基本的に feature ブランチを作って、push して、他の人に公開する準備が出来たら、
> > Pull Request を作ってマージするという流れになりますよね。
> > その際、他の人のレビューを通せるのと、CI やコードチェックツール等を自動で実行することにより、
> > コンパイルが通らないようなコードを本流に入れるのをある程度防げると思います。
> いまの Tera Term プロジェクトには、すべての変更にレビューを通せるだけのリソースはありません。
> コミットして、誰かに見てもらいたくてお願いしても、なんの返信もなくそのままになることも多々あります。(その場合は、それがそのまま生きになります)

他の人によるレビューが期待できなくても、
CI やコードチェッカーによるチェックは期待できます。

また、Pull Request の形にすることで、セルフレビューすることもできます。
自分で意図しない修正を入れてしまっていることに気づくことができたりします。

>
> > GitHub にも wiki はあります。
> 自分のリポジトリで表示されなかったので、無いものと思いました。有効にすればいいんですね。

Private リポジトリの場合は、wiki を使う場合、有料プランに入ってないと使えないです。
Public リポジトリの場合は、何もしなくても有効になっていると思います。
(設定で On/Off できます。もし Off になっている場合 On にできます。)

> > storage というのはどういう用途で使用しますか?
> 手元でビルドしたスナップショットや、その他の何かを置くことがあります。
> https://osdn.net/projects/ttssh2/storage/snapshot/
> https://osdn.net/projects/ttssh2/storage/tmp/20220914_zmatuso/
> storage は issue などへの添付で代用できるように思えます。

『手元でビルドしたスナップショット』に関しては CI を組み込むことにより
単に CI のビルド URL を共有すれぱよく、自分でビルドする必要はなくなるかと思います。

例えば、
https://github.com/m-tmatma/ttssh2migrate/actions/runs/3642079612
というような感じです。

CI でビルドすると Artifacts として成果物をダウンロードできます。
ただ (GitHub Actions の場合) Artifacts の保持期間は 90 日なので
それ以上保持したい場合は、チケットなどに添付して保存しなおす必要がありますが。


> > アカウント名.github.io という名前の git リポジトリを作ることにより、その内容を公開することができます。
> それは、過去のドキュメントにも載っている https://ttssh2.osdn.jp という公式サイトを引っ越す、という意味になります。
> > 時間の経過とともに解消していくかと思います。
> 今の公式サイトも、寺西さんのホームページ(https://hp.vector.co.jp/authors/VA002416/)のほうが上位にいた期間がかなりあったそうです。「OSDN はアーカイブにする」と決定したとして、どうアナウンスするかですね。
> また、検索エンジンの下位だとしても、ここ(https://osdn.net/projects/ttssh2/releases/)に来れば「ずっと更新されていないリリースたち」という状態になります。
> さらに、ここ(https://ttssh2.osdn.jp/manual/4/ja/)にマニュアルを checkout していて、多くの参照があると思われます。引っ越し後にここを放置すると「ずっと古い情報のまま」になります。

GitHub Pages に全部持ってきて、
https://ttssh2.osdn.jp/manual/4/ja/https://osdn.net/projects/ttssh2/releases/ には
GitHub Pages へのリンクを追加するのではどうでしょうか?
Responder al #92870

Re: git への移行 (2023-01-05 03:38 by nmaya #93243)

> rebase すると commit hash が変化するので、commit hash を直接人が参照することに意味がなくなってしまいます。
> 後で参照する場合は commit hash を参照するのではなく pull request の番号を参照します。

https://osdn.net/projects/ttssh2/svn/view/branches/4-stable/doc/ja/html/about/history.html?root=ttssh2&view=log#rev10244

このように、今は「ある修正」について言及するときにリビジョン番号を使うことがよくあります。rebase すると消えてしまう(親として参照されなくなるだけで本当は消えていない?)ので、GitHub では特定のコミット(PRに含まれる複数のコミットのうちの1つ)を指すことができない(そういう運用をしない)という理解をしていいのでしょうか。blame では PR ではなく commit hash で見ることになりますし、そういうものと言われればそうなのかもしれませんが、対称性がない感じがします。


> GitHub Pages に全部持ってきて、
> https://ttssh2.osdn.jp/manual/4/ja/https://osdn.net/projects/ttssh2/releases/ には
> GitHub Pages へのリンクを追加するのではどうでしょうか?

Webページのほうは.htaccessを頑張って書けば、該当する同じページにリダイレクトできるかもしれませんね。

OSDN にはないと思いますが、GitHub のアーカイブされたリポジトリ(例:https://github.com/PHPOffice/PHPExcel)みたいに、プロジェクトのどこのページでも「終わってる」ことがわかりやすく出せればよいのですが。
Responder al #92894