2020年を振り返りたい
2020年も終わりなので、振り返り記事でもと思ったら、2020年中には記事3本しか書いてなかったですね。
「フリック入力ミスったー」は、諸々調子が良くなってきたところで、時間をちゃんと作ってちまちまやれば一応物は作れるなと自分なりに確認できた感じです。
他2本は記事と言うか、昨年から引き続いてる件だったり、告知みたいなものなのでここで改めて書くことは特に...
特に記事にしてない振り返り
今年1年を通してはご多分に漏れず、リモート対応なりで家にいる時間が長くなり、もともと毎日出勤みたいなスタイルではありませんでしたが、確かに調子を整えやすくはなったけれどパフォーマンスとしてはどうやろね？ というのはありました。
じゃあその期間に何か作ったり、というのも考えなくはなかったですが、調子が良くなったのと合わせて作品を鑑賞するモチベーションが回復してきたので、そういうインプットに当てたような感じです。
これは3年半ほど続いていた心療内科への通院が(結果的に)今年11月に終わるぐらいには回復傾向が強くなっていたので、生活サイクルの維持に努めた方が良かろうと思っていたのもあります。
(通院時に、家にいる時間が長くなったのがいい影響になったんじゃないかという話があったりしましたが、まあ正直なところよくわかりません)
あとはまあ、活用できる制度は諸々活用しつつ、何となく講談社のアレにとりあえず1本投げてみたり、TorqueLリリースから6年経ったね、と言う感じでしょうか。
来年に向けては、一応緩解したので環境を変えたり見直した方が良いかなということで、年明けて少ししたら引っ越しを予定してます。(6月からちまちま探してて最近物件が決まりました)
まあどうなるかわかりませんが、とりあえず生き延びています。よいお年を。
商標登録第6121255号「トルクル」への異議申し立てについて、決定が通知されました(商標登録は維持されました)
だいたい1年2か月ほどかかりましたね。
商標登録第6121255号「トルクル」への異議申し立て(異議番号 2019-900082)について、決定が通知されました。
異議申し立ての内容は過去記事に書いてあるので、そちらの参照をお願いします。
決定にかかる文書(異議番号 2019-900082 )はおいおい J-PlatPat や 商標審決データベース などで公開・公報されると思いますので、 以下に自分なりに決定の内容を要約しておきます。
(あまりに長期間公開されないとかだったら文書のスキャンなども考えます)
2020.12.26 追記
商標審決データベースで異議の決定が公開されていましたので、以下にリンクを置いておきます。
異議の決定｜異議2019-900082 - 商標審決データベース
- 当該商標の「トルクル」とTorqueLの読みの「トルクル」については、指定商品(第9号)の商標として類似性が認められる、しかし自分が示した証拠類では(特に量的に)需要者への周知性は認められない。
- 上記から、商標法第4条第1項第10号(他人の周知商標)に該当しないため、商標登録は維持する
他、個人的に気になったところを目についたところ書いておくと
- 指定商品の解釈については同一区分(9類)であることが認められているが、商品としての類似性は否定されている。(両商品の目的、用途、流通部門及び需要者等が異なる)
というところかと思います。
自分が示した証拠類は、既に広報・発売されていたことを示す記事ややりとりが主で、具体的な数値(例えば本数や視聴率)は強く示してはいませんから、 需要者への周知性を認められるには難しい面があることは想定できることだったので、ありうる決定でした。
今回異議申し立ては認められませんでしたが、過去記事でも書いた通り、 商品・役務として直接衝突するものではないと思われるため、先使用権の主張のための法的手続き、当該商標の無効審判手続きなどは行わない予定です。
異議申し立て書を作成する際に相談させていただいた方々、提出後に対応いただいた特許庁の方々へこの場を借りて改めて御礼申し上げます。
Qiita投稿記事をはてなブログに転記しました。
Flutter(for web)で"フリック入力ミスったー"を作った
表題の通り、Flutter(for web)を使用してフリック入力ミスを再現するWebアプリ、「フリック入力ミスったー」を作成しました。
フリック入力ミスったー/Flick Input Mistake Simulator
手元にある範囲でしか動作確認できてませんが、大体のブラウザで問題なく動作すると思います。
"フリック入力ミスぉたーというWebアプリを作りぁしたみじひ試ちてみてくなさい。"
— FullPowerSideAttack.com (@fpsacom) 2020年3月7日
(フリック入力ミスったーというWebアプリを作りました。ぜひ試してみてください。)
https://t.co/iWx3puI2p7 #フリック入力ミスったー #FIMSimulator pic.twitter.com/IOiEIhhgoo
フリック入力ミスをあえて再現してみるWebアプリ、 #フリック入力ミスったー を作りました。
— なんも/Nanmo (@nanimosa) 2020年3月6日
手元にあるPC,スマホでしか動作確認出来てませんが、大体のブラウザで動作すると思います。
いろんな文章をシミュレートしてツイートしてみてください。https://t.co/zUAbfsejTl #FIMSimulator pic.twitter.com/cov1nvtjeX
"Q(・のブラウザでの動いちゃづぞ、づりおスクショです。(いもなす)"
— なんも/Nanmo (@nanimosa) 2020年3月7日
(PS4のブラウザでも動いちゃうぞ、というスクショです。(いみなし))
https://t.co/zUAbfsejTl #フリック入力ミスったー #FIMSimulator pic.twitter.com/hbnfty4sqk
制作中、Android向けにビルドして動作確認もおこなっていますが、Android/iOSアプリとしてリリースする予定は今のところありません。
制作メモ
フリック入力によるミスのうち、タッチ開始位置を間違えたり、フリックする方向を間違えたりするのをあえて再現することに面白みがあるんじゃないかと考えついて、今作るならReactでWebアプリかな？ と思って調べつつ作りつつFlutterに移行しつつで大体一か月ぐらいで思いついた程度の実装が済んだので公開しました。
Reactから始めたはずがFlutterになったのは、
Reactのドキュメントを読み込んでJavascriptでざっくり作る
->Material UI導入してUIを付ける
->スタイリングが面倒そうなことに気づく
->進捗を方々に見せつつReact Native(for web)に移行した方が良いのでは？ と考え始める
->Flutter(for web)という手もあると教えてもらう
->React Native, React Native(Expo), Flutterをそれぞれ調べつつ比較する
->事情はよく分からないが、React NativeのSliderがDeprecatedになっていることが気になる
->Betaだけどそこそこまともに動くみたいだし、Flutter(for web)でええか...
という経過をたどったからです。
フリック入力ミスを再現するのにあたっては、事前に考えていた機能設計で文字列と連想配列と2次元配列が扱えれば問題ないと判断していたので、JavascriptからDartに移行するのも抵抗はありませんでした。(いざやってみると、文法の違いや何やらで戸惑う点はありましたが)
フリック入力ミスを再現する仕組み
ひらがな、ローマ字、数字といった入力パネルをキーとして連想配列(Map)を作成し、Mapのバリューとして入力する文字を並べた2次元配列を用意しました(1次元目がタッチ位置に、2次元目がフリック方向に対応する)、これを一文字ずつ照らし合わせて、該当するものがあればタッチ位置ミスやフリック方向ミスの判定を行って、タッチ位置ミスであれば1次元目の選択をランダムにずらし、フリック方向ミスであれば2次元目の選択をランダムにずらして選択・表示する、というやり方です。(二つのミスは独立に判定しているので、両方発生する場合もあります)
//Dart static const Map flickInputTextMap = { 'hiragana': [ ['あ', 'い', 'う', 'え', 'お'], ['か', 'き', 'く', 'け', 'こ'], ['さ', 'し', 'す', 'せ', 'そ'], ['た', 'ち', 'つ', 'て', 'と'], ['な', 'に', 'ぬ', 'ね', 'の'], ['は', 'ひ', 'ふ', 'へ', 'ほ'], ['ま', 'み', 'む', 'め', 'も'], ['や', '「', 'ゆ', '」', 'よ'], ['ら', 'り', 'る', 'れ', 'ろ'], ['わ', 'を', 'ん', 'ー'], ['、', '。', '？', '！'], ], //以下パネルごとにMap定義が続く
ローマ字・数字の入力パネルや、ひらがなも濁音・半濁音で被る文字があるので、照らし合わせる前に入力パネルの順番をシャッフルするような処理も入れています。
該当する文字が無い場合は全走査することになるので、最悪1文字ごとに3次元配列にアクセスするような感じになるので、自動実行の際は最大文字数を設定して制限するようにしています。
上の方法でのシミュレートは、変換ミスや、パネルを間違えるといった場合が含まれないことになりますが、てにをはの間違いぐらいが面白みがあると思っていたのと、実装難度のバランスを考えてこうした方法になっています。(漢字を開いてさらに間違えてどうこうとかやりたくなかった)
中華フォント問題
Flutterでビルドしたアプリが日本語で動作させるといわゆる中華フォント問題が発生することがあり、いくつか解決法があるようなのですが、今回は flutter_localizations を使ってサポート言語に日本語のみを設定する方法をとりました。(そのうち公式に修正されるかもしれないので、いつまでこういった類の作業が必要なのかは謎)
//Dart //Flutter 1.14.6 / channel beta import 'package:flutter_localizations/flutter_localizations.dart'; //中略 class MyApp extends StatelessWidget { // This widget is the root of your application. @override Widget build(BuildContext context) { return MaterialApp( title: 'material app title', localizationsDelegates: [ GlobalMaterialLocalizations.delegate, GlobalWidgetsLocalizations.delegate, ], supportedLocales: [const Locale('ja', 'JP')], //後略
作ってみて
- 型が無いのはやっぱり辛い時もある(React/JSでイベントオブジェクトという名の別物に行き当たった)
- Flutter/Dartはドキュメント自体はそろっているけど、やっぱりまだ日本語のドキュメントが少なく感じた。
- Widget of the Weekはいい取り組みだと思う
- Flutterのウィジット/コンポーネントは種類も機能も充実しているが、同じ機能を実現するのにいくつも手段があるので、それはそれで面倒に感じた。
- React/Github Pagesで考えていたものが気がついたらFlutter(for web)/Netlifyになっていた。どういうことなの...
- ReactもFlutterもsetStateしたあとのStateの更新タイミングで結構困りがちだった
(予定はないけど)更新するなら
- 入力パネルの順番シャッフル頻度の調整
- 今だと文章全体のルーチンが始める前に一回シャッフルするだけなので。ただ、あまり頻繁にやるとメモリを食いつぶすような気もして微妙。
- UIの調整
- 変換対象テキストと変換後テキストの位置が離れているので、UIコンポーネントの順番を入れ替えるか、オプションをまとめて閉じておくことができるようにする
- 多言語対応
- 英語切り替え対応はしたいけど、そもそも日本語圏以外でフリック入力ってどういう扱いなんやろか...
- アイコン
- 各ストアのアプリで出すなら、Flutterデフォルトのじゃないのがやっぱりほしい
最後に
「フリック入力のミスを再現するアプリ」のアイコンってなんだよと思いながら、マテリアルデザインのドキュメント読みながらひねり出したのが次の画像になります。
以上です。
2019年を振り返る振り返る
特に大きな活動はありませんが軽く一年を振りかえってみる記事です。
1月
2018年末あたりにVRM化した100ポリモデルを、VRoid Hubに持ち込む際にあった色々をまとめた記事です。
さすがに11か月も前となると、サービスの仕様が変わっていそうですが、最近はどうなんですかね？
pixivさん仕様面などへの問い合わせに回答頂きありがとうございました。
3月
ゲームソフトウェアを含む、第9類区分での「トルクル」商標登録への異議申し立てを行いました。
現在までに、特許庁から異議申し立て番号も通知され、補正命令への対応などを行いました。
結果がわかったらまた記事にすると思います。(通るにしろ通らないにしろ参考になるとは思うので)
でもまあやはり、異議申し立てはお金もかかる手続きなので、可能なら審議中に情報提供しておいた方がベターだとは思います。(どうやって、どのタイミングで気づくかという問題もありますが)
5月
Indie-Streamのサイト閉鎖に伴う情報のFANBOXへの移転や、Steam版トルクル(TorqueL)のパブリッシャー変更(セルフパブリッシングからPLAYISMパブリッシング)、あとトルクル(TorqueL)のステージをモチーフにしたスマブラのステージを公開しました。思ったより活動してた。
パブリッシャー変更に関して何か書こうかと思ったけど、fanboxに書いてあるので十分な感じでしたので、こちらからは以上です。
3月から6月にかけて断続的に
スマブラのスマッシュや、鉄拳のバウンドコンボの爽快感を抽出したようなのはどうかなーとUnityを色々いじってました。
弾いたり、引っ張ったりして飛ばすアクションは最近そう珍しくない感じですが、そこにゴルフ、もといスピードゴルフ(実在する競技です)を混ぜ込んだ架空スポーツ的な感じでどうやろと仮組していましたが、ゲーム全体のデザイン方法がピンとこなかったので、とりあえず塩漬けにしてあります。
特にマップ・ステージの作りをどうするかというあたりが難儀で、有機的な(?)形をとれるようにしたい感じだったのですが、今んところいい手は思いつきませんでした。
8月
BitbucketのMercurial(hg)サポート終了が予告されたので、Gitへ移行をやってみた記事と、Gitに移行したついでにGit-LFSも導入してみる作業とそのメモを記事にしました。
実際にサポートが終了するのは2020年6月1日あたりのようなので、時期が近づくとまた需要がある感じでしょうか。
10月
トルクル(TorqueL)のDL/デジタル販売価格を改定しました。
理由とかはFANBOXの記事で十分かなと思うので、そちらのほうで。
いざやってみると、やはり各ストアへの準備とか、セルフパブリッシングとそうでないものの混じり合いとかでたいそう面倒なので、そう気楽にやるものではないですね...(2か月ぐらいかけて調整してた気がする)
12月
12月24日でトルクル(TorqueL)リリース5周年でした。
本日はトルクル(TorqueL)を製品版として初めてリリースしてから、ちょうど5周年となります。
— FullPowerSideAttack.com (@fpsacom) 2019年12月24日
特別な催し等はありませんが、年末ということもあってPS StoreやSteamでセール中です。
引き続きよろしくお願い致します。https://t.co/Drz1aenjqa#TorqueL #トルクル #Unityっぽくない #unity3d #indiedev pic.twitter.com/udjNs1MWil
特に催しとかはありませんが、引き続きよろしくお願い致します。
ここ最近のこと
9月あたりから、Kindle Paperwhiteを投入して、100件に届きそうになっていた積み本(デジタルだけど)*1をいい速度で消化できるようになってきました。(読んだ分さらに続きを買っていたりもするので、大体20件前後を積みながら消化しています)
それに加えてFGO(アニメ), 仮面ライダーゼロワン, 孤独のグルメ(ドラマ)あたりを毎週録画してみていますが*2、気を抜くと数週分溜まるので、やはり本にしろゲームにしろ、アニメをはじめとする映像作品にしろ、心身健康でないと新しいものに触れていくのはやはり難しいなと、思いを新たにしました。(ほかにも色々触ってはいますが、まあたまにTwitterでつぶやいてるのでそれで)
調子が戻ったぐらいだと、停滞した分はそのままなので、どうしたものかなと思いますが、まあどうにかなるんじゃないでしょうか。多分。多分?
どうも活動そのものができないことと、センサー各種が正常に動いていないのが併発するため、正常になる過程で、センサーだけが正常化したことによって、活動量が横ばい、またはむしろ下がるような状態になることがあります、活動量という結果だけでなく、プロセスも考慮してみる必要があるようです。(プロセスだけ見てもダメではあるので、程度問題ということになるかと思います)
それでも10月のころから比べると、引き続き減薬しつつ、より思考を巡らせたり・深めたりができるようになってきています。
とはいえ、この状態に戻るまでの間に体力的なところや技術的なところは落ちていたり、下がっていたりするので、改めて習得していく必要があるので、そこはやはり気が重いところではあります。
そう思って、色々予定を立てたりすると片頭痛や体調不良でアカン*3みたいなことはやっぱりあるので(この記事を書くのですら若干その傾向がありました)、どうにか前向きにやっていきたいと思います。
ここまで書いて、はてなブログとFANBOXの使い分けが相変わらず適当なことに気づきましたが、うーん、どうしましょうね...まあ、そのうち...(先延ばし)
git lfs migrate で Git-LFS 移行したときのメモ
Mercurial(Hg)からGit移行移行したついでに、ほぼ1GBとかあるリポジトリ*1をGit-LFSに移行した際のメモです。
Git-LFSを扱えるサービスとしてはBitbucket CloudよりもGitlab.comの方が制限が緩かったので、そちらへの移行も同時に行いました。
作業環境: Windows 10 + Git for Windows(+Git Bash,Git LFS)
- 0. BFGを使わなかった理由
- 1. Bitbucket Cloud から --mirrorでクローン
- 2. git lfs migrate info による事前調査
- 3. git lfs migrate import 実行
- 4. Gitlab.com へ --mirror でプッシュ
- 5. 参考資料ほか
0. BFGを使わなかった理由
Git-LFSへの移行(変換)を調べているとBFGを使った移行方法の説明が多く見つかります。
AttlasianやGitlab.comもBFGを使用した移行ドキュメントを公開しています。
ところが、ドキュメント通りにBFGによるGit-LFSを実行したところ、一見問題なく移行できたように見えて、実はうまくいってないのでは？ という状態になり、色々調べ直したところ、現在は git lfs migrate で問題なく移行できるというところに行きつきました。*2
BFGでのGit LFS移行について、自分の環境で問題になったのは以下の点です。
- BFGが生成する
.gitattributesファイルはオプションで指定した文字列がそのまま入ってしまう関係上、Git-LFS的に無効なフォーマットで生成される場合がある。(これにより、問題なくgit lfs pullできるが、git lfs管理のファイルがModifiedな状態として認識される事態が発生した)*3 .gitattributesファイルが、ルートになるディレクトリだけでなく、対象となるファイルがあるフォルダ毎に生成されてしまう。*4(1.の問題に引っかかると認識しにくいが、リポジトリ内を一括で変換してるのにディレクトリ毎に.gitattributesファイルを管理することになるのはうれしくなかった)
1. Bitbucket Cloud から --mirrorでクローン
git clone --mirror git@bitbucket.org:[ユーザー名]/[リポジトリ名].git
※クローンした [リポジトリ名].git を別にコピーしておくなり圧縮して置いておくなりすると、繰り返しテストする時など大変便利がいい。
2. git lfs migrate info による事前調査
クローンした[リポジトリ名].gitフォルダに移動したのち、現在の状態を調査
git lfs migrate info --everything
上記を実行すると、リポジトリに含まれるファイルのサイズを拡張子毎に集計して、容量降順に並べて表示してくれる。 デフォルトだとトップ5の拡張子まで表示してくれる。
--everything は全ブランチを対象にするオプション。
git lfs migrate info --top=20 --everything
だと、トップ20まで表示してくれる。
あくまでも拡張子毎に集計しているだけなので、.csなども普通に入ってくる。
参考にしつつ、対象となる拡張子(またはファイル)を選定する。
なお、このgit lfs migrate infoでは拡張子の大文字小文字も厳密に分けて集計される。 これはのちに実行する変換コマンドでの指定でも同様なので留意する。
バイナリだからとにかくGit-LFSに移行すればよいってものでもないと思うので、そこの判断は慎重に行う。(あとマイナー?な拡張子はバイナリかどうかの判断に困ったりもする)
3. git lfs migrate import 実行
[リポジトリ名].gitフォルダ内で、Git LFSに移行するファイルを指定してgit lfs migrate importコマンドを実行する。
git lfs migrate import --include="[Git LFSに移行するファイルの指定]" --everything
--include でのファイル指定はワイルドカード(*)が使えるので、拡張子を指定する場合は *.[拡張子] で指定する。複数指定がある場合はカンマ(,) でつなげていく。
例として、以下の指定だと、拡張子wav,png,bmp,zipのファイルが移行対象になる。
git lfs migrate import --include="*.wav,*.png,*.bmp,*.zip" --everything
※細かい指定方法などは git-lfs/git-lfs-migrate.1.ronn at master · git-lfs/git-lfs · GitHub を参照のこと。
あまり指定が長くなるようなら、(Git Bashなので) \ でつないで複数行にする。
git lfs migrate import の実行が完了したら、以下のコマンドで、ローカルのファイル・キャッシュを整理する。*5
git reflog expire --expire-unreachable=now --all && git gc --prune=now
リポジトリのルートディレクトリに .gitattributes が追加されているので、--inlude で指定したファイル名、パターンが問題なく記述されていることを確認する。(履歴も改変されて.gitattributesが最初期にコミットされたことになっているはず)
また、git lfs migrate import 実行後に git lfs migrate info を実行すると再度集計できる。この時Git-LFSに移行したファイルはポインタファイルでの集計になっている。これは移行の確認や効果の見直しなどに使う。
4. Gitlab.com へ --mirror でプッシュ
Gitlab.comで新しく作ったGitリポジトリへプッシュ
git push --mirror https://gitlab.com/[ユーザー名]/[リポジトリ名].git
既になにかしらあるリポジトリへも --mirror だとforce扱いでpushできるが、それは結構な荒療治なので諸々確認が必要になる。 (なので新しいリポジトリにpushして移行する形にしている)
※リポジトリのURI形式がBitbucket CloudとGitlab.comで異なるのはたまたま作業していてそうなっただけで特に意味はありません。
5. 参考資料ほか
Bitbucket CloudのMercurial(Hg)リポジトリをGitリポジトリに移行したときのメモ
Bitbucket CloudのMercurial(Hg)サポート終了、そして最終的にはHgリポジトリは削除されるということで、Btibucket CloudのGitに変換・移行した手順のメモです。
当初は、ほならサクッと変換してパパっと移行して終わり！ と思っていたところ、いざHgからGitに変換・移行方法を色々調べてみると、あっ、これ存外に面倒くさいな？ という感覚を得たので、移行しながら書いたメモを残しておきます。
作業環境: Windows 10 + TortoiseHG + HgGit + Convert Extension のPCで作業
HgGitは本来Hgコマンド群でリモートのGitリポジトリを管理運用するツールですが、今回はGitリポジトリへの移行のためだけに使用します。そのため、移行したリモートGitリポジトリをHgGitで管理し続けていくという場合には本稿の手順だけでは不十分かと思います。
- 1. Bitbucket CloudのhgリポジトリをローカルにCloneする
- 2. コミットログのauthor名を変換(統一)する*1
- 3. gitのbranchとしてhgのbookmarkを適宜作成する
- 4. Bitbucket Cloudで移行先となるgitリポジトリを作成する
- 5. 移行先のBitbucket Cloud GitリポジトリにPushする
- 参考文献など
- 今回使わなかった移行方法など
- おわりに
1. Bitbucket CloudのhgリポジトリをローカルにCloneする
Clone完了後は失敗時のリカバリやオリジナル保全のため、ローカルでhgリポジトリを触る前に、Clone直後の状態を圧縮するなりコピーするなりしてとっておく。(HgGitの影響で何かしら操作すると.hg内にGit用ファイルが生成されたりもする)
2. コミットログのauthor名を変換(統一)する*1
特に古いリポジトリなどでPC移行や表記ゆれなどがあり、コミット時のauthor名が統一されていないものがあった。
移行を機にauthor名を統一することにして、Convert Extensionでリポジトリを変換を利用する。
今回は今現在GitHubで使っているauthor名に統一した。(将来もしGitHubに持っていくとなったときに便利なので)
author名変換リストを作成する。
一行ごとに
[旧author名]=[新author名]
と書いたテキストを用意する。
コミットログからauthor名を抽出する
コマンドプロンプトで各リポジトリのディレクトリに移動して、hgログ出力からauthor名表記の行を抽出する。
hg log | findstr "ユーザ:"
※hgが日本語設定になっていたので"ユーザ:"表記で抽出、英語だとおそらく"user:"
Windows cmd標準でuniq的なコマンドが無いので*2、出力を目視確認して必要なものをauthor変換リストに記載する。
バッチファイルを作って必要なリポジトリのhg log全部叩いたのをユニーク抽出して一発でauthor変換リストを作るやり方もあるなと思ったけれど、今回はそこまでやらなくてもいいかなという規模だったので、コンバートするリポジトリごとに実行して、適宜author変換リストに追記した。(最終的には12種あったauthor名を1つに集約)
変換するリポジトリの一つ上のディレクトリから、author変更のリポジトリ変換を実行
hg convert --authormap [author変換ファイル] [変換元リポジトリ名] [変換後リポジトリ名]
変換後リポジトリは自動に生成されるので、フォルダなどは事前に作らず、変換元リポジトリ名-converted とした。(※指定していない場合は -hg が付いたものが生成される)
変換後すぐは.hgしか存在していないので、updateで最新のファイル状態に復帰させて諸々確認する。
hg update
author名が統一できておらず、author名変換の対象になったBitbucket Cloud hgリポジトリは15個中11個だった。(非公開設定のものを含む)
3. gitのbranchとしてhgのbookmarkを適宜作成する
基本的にはhgのbranchを使って運用していたリポジトリにのみ実施する。
hgとgitでbranchの概念や扱いが異なっており、HgGitにおいてはbookmarkがgitのbranchに対応する。
hgリポジトリのbranchを確認
hg branches -c
※-cオプションで閉じたブランチも確認
必要に応じてブランチに対応するブックマークを作成する。
hgのdefaultブランチをGitのmasterブランチに対応させる場合のコマンドは以下の通り。
hg bookmark -r default master
※明示的にGitのbranch(hgのbookmark)を作らなかった場合、Pushはできるが何も見えず容量だけ消費しているGitリポジトリになることがある。今回は15個中2個のリポジトリで発生したが、上記のように明示的にmaster bookmarkを作成してから再度Pushしたところ正常に確認できるようになった。(なので、おまじないとして全リポジトリでとりあえずやっておくというのもありかもしれない)
特に変名する必要のないブランチは -hg を付けたブックマークを作成(ブランチと同名のブックマークは作成できないため)
hg bookmark -r [ブランチ名] [ブランチ名]-hg
作成したブックマークを確認
hg bookmarks
最終的にブランチ移行が必要なhgリポジトリは15個中3個だった(元々ブランチを多数作っていたリポジトリ1個、hg defaultをGit masterに対応させる必要があったもの2個)。
4. Bitbucket Cloudで移行先となるgitリポジトリを作成する
元となるBitbucket Cloud hgリポジトリ名に -git を付けたリポジトリを作成する。 public/private設定などの各種設定もhgリポジトリに準じたものとした。
Bitbucket CloudでリポジトリのURLはリポジトリ名がそのまま利用される、リポジトリ名は後で変更が可能なので、公開リポジトリなどで同じURLを維持したい場合は元のhgリポジトリ名を -hg を付けるなどして変更した後に移行したGitリポジトリ名を元のリポジトリ名にするという手段がある。
5. 移行先のBitbucket Cloud GitリポジトリにPushする
sshの公開鍵認証によるPushになるので、Bitbucket Cloudに公開鍵の登録と、ローカルのsshクライアントへの秘密鍵の登録を済ませておく。
今回はTortoiseHg付属のPageantを使うので、Pageantに秘密鍵を登録して、起動した状態にしておく(閉じていてもタスクトレイにいればいいはず)。
鍵生成や登録設定については、Atlassianのサポートに記事があるので本稿では割愛する。
Bitbucket Cloud GitにPush
hg push git+ssh://git@bitbucket.org/[ユーザー名]/[Gitリポジトリ名].git
コマンド完了後にBitbucket CloudのGitリポジトリを確認して終了。あとは置いておくなり、Gitクライアントからいじるなり、リポジトリ名変更までやって移行するなり。
今回はGitへの移行までなので、これだけ。HgGitのまま使い続けるのであれば、毎回URI書くのは手間なので、 .hg/hgrc に各種パスを記述したりするなどいろいろな設定が必要になるはず。
移行したリポジトリ群
公開リポジトリは長年放置してあるものが多いですが、本手順での移行の参考にどうぞ。
リポジトリ名末尾に-hgold が付いているリポジトリが移行元になったhgリポジトリです。
参考文献など
今回使わなかった移行方法など
- Bitbucket Cloudでリポジトリ削除するときには移転先URL表示するようにできるので、同名URLにこだわれなければ何かしらで移行した別名リポジトリに飛ばすとかでいいかも(でもオリジナル消すの怖いよな...)
- GitHub.comのimportツールで移行すると、おおむね問題なさそうだったが、コミットメッセージの日本語が化けてしまったので利用せず
- Gitlab.comのBitbucket Cloudインポートは今のところgitリポジトリしかインポートできなかった
- fast-exportは今回の移行方法よりも実行環境を整えるのが面倒そうだったので試さなかった
おわりに
Git移行したんやからでかいリポジトリ(TorqueLのリポジトリがほぼ1GB)はGit-LFSに移行したろ！ と思ったらこれまた面倒な感じだったので調査と検証中...
