ラベル mercurial の投稿を表示しています。 すべての投稿を表示
ラベル mercurial の投稿を表示しています。 すべての投稿を表示

2014年3月23日日曜日

「mercurialに巨大なファイルをcommitしてpushしたら、誰もpull出来なくなった！」→壊れた？？→（と思ってるアナタへ）

っと言うことが出稼ぎ先でありました。ファイル1個１GB。確かにデカイ。
コマンドラインだと、addするときに警告が出るはずですが、これは、TortoiseHG の気が効かないのか、或いは見落としたのか？

  • 結論から言うと、リポジトリは無事なのですが、
  • mercurialは、リポジトリ通信をするときにチェンジセットの圧縮展開をオンメモリでするらしく、
    • 特に hgwebdir.cgi は、メモリの狭いサーバで動かしていたので
    • そこで落ちてました。
  • 幸か不幸かmultiple headは禁止しており、
    • 問題のブランチは誰もチェンジセットを足せてないので、
  • 問題のチェンジセット以降を破棄したほうが良さそう。
特定のチェンジセット「以降」を破棄して良いなら方法はあります。
知らない人が多いかもしれません。 clone/pullはチェンジセットID＆ブランチを指定できます。

いずれも -r です。

http://selenic.com/hg/help/clone
http://selenic.com/hg/help/pull

-r --rev REV [+] include the specified changeset
-b --branch BRANCH [+] clone only the specified branch

より若い番号から始めて、指定のチェンジセットまで吸ったら停止します。
  1. 新しいディレクトリに、その他のブランチだけをcloneする
  2. 問題のチェンジセット以前を指定して、pullする。
  3. 新しいディレクトリの .hg を、公開リポジトリの .hg と入れ替える。
    1. ファイルコピーじゃ駄目です。
    2. ディレクトリごと入れ替えます。
  4. apacheを再起動、とかは要りません。hgwebdirはリアルタイプでリポジトリを見てます。

この手のトラブルは、mercuria 1.Xだと思われます。もちろん本家もこれ系の問題は認識しており、2.0では巨大ファイルの通信方法から変えたりしてるらしい。
http://mercurial.selenic.com/wiki/LargefilesExtension

時刻:
ラベル:

2013年3月24日日曜日

mercurialの付属エクステンション

標準構成でもある程度使えてしまうmercurialですが、いやあ最近めっきりサイト見てないんで出遅れてますねだいぶ。

なんでこれが標準で入ってないの？
っていうぐらい便利なエクステンションが結構あります。

progress http://mercurial.selenic.com/wiki/ProgressExtension
経過表示が付きます。gitだと標準ですね。


なんでコレが標準になってないのか小一時間問い詰めたい。終了予想時刻もでるので、安心してコンビニに行けます。デカいリポジトリをcloneするときなんか非常に重宝します。あーもう待てない。諦めて寝ます。

EOL Extension http://mercurial.selenic.com/wiki/EolExtension
テキストファイル中の改行コードを勝手に変換して統一してくれるらしい。Windows/Linux/MacOSが混在してる職場で重宝しそう、というかまさしくそれが目的でしょう。

Purge http://mercurial.selenic.com/wiki/PurgeExtension
ワーキングファイル群のうち、リポジトリに入れてないものをバッサリ削除します。origとかrejとかbakとか消すのにはいいのですが、その他も消えます。消えすぎに注意。デプロイ作業とかにはそれなりに重宝しそうです。

GraphLog http://mercurial.selenic.com/wiki/GraphlogExtension
テキスト表示でも、アスキーアートでブランチの具合を表示してくれます。

Share http://mercurial.selenic.com/wiki/ShareExtension
唯一のローカルリポジトリを、複数のワーキングディレクトリ間で共有します。複数のブランチを渡り歩くような運用にかなり重宝しそう。例えば「今バグ直してるんだけど、とりあえず別件で別ブランチでデプロイして試したい」とか。hgrcファイルは別なので、コッチだけpurgeを適用するとかもアリでしょう。一昔前だと、hookとpushでも運用できそうなケースではありますが
時刻:
ラベル:

2012年9月16日日曜日

gitに移行するのは、「mercurialの◯◯が嫌いだ！」と言えるようになってからでいいと思うよ

git、使ってますよ。

githubとかgistは使ってるので、どうしても使わざるを得ません。元々はbitbucketで追いかけてたオープンソースがgithubに移行したので仕方なく、でしたが、実際、gistも便利ですしね。

分散バージョン管理、数ありますが、容易度(難易度ではない)で言うと。

bzr? ＞ mercurial ＞＞＞＞越えられない壁＞＞＞git

いや、実際、判らないですよ。git

出稼ぎ先のスタッフは、mercurialでの運用には、2週間で概ね慣れてくれました。実際簡単です。トータスHGの存在は割り引いて考えるにしても。

小生が使い始めたのはmercurialが0.7まで遡りますが、コマンドライン数回叩いて、納得できましたから。subversionに極力「似せてる」のもポイントですね。 pushは、簡易なデプロイ機能として使えますし、オマケに現地でのパッチをスムーズに吸い上げることが出来る！こりゃ凄い。てなもんでさ。

機能的にはgitでも勿論出来ますが、

問題は、「出来るか否か」ではありません。
「使うことがメリットになるか(厳密には使いこなせるか)どうか」です。
使いこなせない機能は「存在しない」も同じ。

gitの判りにくさの原因の一つは、異なるコンテキストの「省略語の管理」が、表面上同列に扱えてしまうところだと思う。

git push origin remote

とか。せめてこう書いてくれれば解るのですが

git push -b origin -r remote

どこが違うのって？まあそうね。心の準備をさせてよ！ってところでしょうか。

originもremoteも、いずれも暗黙の省略後。「設定した覚え」がないのに使え、って言われてもピンと来ません。 何度か .git/configを手で書き換えたことがあるほどですよ。

まあ要するに、「gitに移行するのは、「mercurialの◯◯が嫌いだ！」と言えるようになってから」でも遅くはありません。

実際、gitのオススメ記事は「mercurialには出来ないけど、gitには出来ます！」的な物言いが多い。気持ちは解ります。小生だって同じ立場ならそうする。でもそれを聞いてもピンと来ません。mercurialに不満がないからね。

最後の、gitの嫌いなところを明記しておきましょう。

git講座のどこを見ても「履歴を綺麗にする」というフレーズが見当たります。「チェンジセットのガベージコレクション」？？？ 参照してようがいまいが、履歴を削除しちゃいかんだろうと。正直、「仕事」ではやっちゃいかんと思う。どちらが正しいか。という議論をする気は毛頭ありません。これは「正義」の問題なので。オープンソースなら問題ありません。「趣味」だから。※もちろん「趣味」を馬鹿にしてるわけでもない。

時刻:
ラベル: , ,

2012年8月24日金曜日

新、mercurial のススメ

出稼ぎ先で、半ば強引に使い始めたmercurial。早1年経っちゃってますが。初のそのプロジェクトも、終盤近くなってまして、更に一部の人員は新しいプロジェクトに移住しつつあります。

新しいリポジトリどうするの？となって、迷わずmercurialが出たのはうれしい限り。

しかも、担当大分類ごとに、ブランチ別けようか、という試験運用まで自分で考え出す始末です。おっと、「大分類」と言いましたが、リポジトリディレクトリの一段目、開発フェーズのグループ単位と言いますが、

  • 企画組
  • プログラマ組 
  • グラフィッカ組 そういや、ゲーム業界では、グラフィックデザイナをグラフィッカと呼ぶのですね。

defaultブランチは開けておいて、リリースはソコにmergeしていこう。という運用らしいです。

これはチェンジセットとマージの本質を理解してないと出てこない発想です。そしてsubversionでは無理過ぎる話。ブランチのコストが高すぎますから。その女性は、mercurialを経験したことにより、バージョン管理の理解が深まったと考えられます。 mercurial中級認定。

イイ話だけでは終わりません。

その新しいプロジェクトは、iPhone開発でして、仕方なくMac miniを何台か買ってたりしてましたが。いや出稼ぎ先の御予算で、です。

そこで私もようやく、MacOSXとmercurialの関係について知りました。どうやらマカーの皆さんの間で、mercurialの普及率はあまりよくないらし。何故ってGUIフロントエンドのバイナリパッケージが見当たらないので。とは言え、それを理由にsubversionに戻すのか？という選択肢はまったく出ないらしく、その意味でも感涙。手段のために手段を選ぶようなことが無くなってきた。

当事者が勝手になんとか調べたらしい & 小生が今簡単に検索したのは次の通り。
無論、コマンドラインでよければ、導入は屁でもありません



昨日一日は、関係者のpush/pullの練習に終始してました。微笑ましい光景です。
時刻:
ラベル:

2012年6月16日土曜日

mercurial requirements dotencode

mercurial 1.9で作ったリポジトリは、mercurial 1.4で読めないらしい。
具体的には、こんな感じで怒られます。

中止: 必須機能 'dotencode' はサポートされていません

もしくは

abort: requirement 'dotencode' not supported!

linuxmintの常用ノートから、ubuntu10のファイルサーバにリポジトリをcloneして、いざそのリポジトリをhgwebdirから閲覧しようとすると、前述のエラーに悩まされるわけです。

小生も泡食って色々調べてしまいましたが、リポジトリが壊れてるわけではありません。
コイツは、「「リポジトリバージョン」の違い」とでも言うべき現象です。

既に出来上がってるリポジトリがどうなってるかは、.hg/requires を見れば判ります。dotencodeを使ってるリポジトリでは、当然最後の行に dotencode が書いてある筈です。ただし、このファイルのdotencodeの行を削除すれば良いかというと、残念ながら違います。リポジトリを正しく読めなくなるっぽいので、後述の再構築をする方が安善でしょう。

http://mercurial.selenic.com/wiki/RequiresFile#Known_requirements
問題のdotencodeは、1.7から増えた機能。MacOS系及びWindows系のファイルシステム対応らしい。故に1.4では読めない。というわけです。しかし流石はmercurial、リポジトリの変換機能(厳密には再構築)は存在します。もちろん1.7以上で実施する必要があります。
hg --config format.dotencode=0 clone --pull 旧リポジトリ 新リポジトリ
幾つか作っちゃったぜ。って人は、仕方がないので一括変換しましょう。

https://raw.github.com/gist/3065657/9c97d72f59e555dd73e9c1af4a6e5f386b0d04d1/oldformat.sh

古いリポジトリも依然として使えますし、1.7以上であればpush/pullできます。
もし、「オレサマはWindowsもMacOSも使わねえぜ」って人であれば、最初からこの機能はoffれます。流石はmercurial。

.hgrcにこんなのを書くらしい。
[format]
dotencode = False
念のため強調しておくと、この設定が効くのはリポジトリの新規作成(init/clone)の時だけです。の筈。前述の変換コマンドラインは、この設定を上書きしつつ処置するわけですね。

更に、このケースが問題になるのは、ローカルmercrialがリモートリポジトリを、直接参照する時だけです。hgwebdir.cgi等を使ってる場合はこれに当てはまりません。リモートのmercurialがリモートのリポジトリを操作しますから。
時刻:
ラベル:

2012年5月19日土曜日

Windows環境でのmercurial運用の注意点

小生はlinux/ubuntuなので全く気にしませんが、Windows(追記、MacOS 12.5でも経験)で使うと、独特のトラブルがあります。

「Windowsでの」大文字小文字の変更でトラブります。

こんな感じで怒られます

abort: case-folding collision between 古い方 新しい方

  • mercurialはファイルのリネームをする場合、「古い名前で削除」と「新しい名前で新規作成」を1回のチェンジセットに捻じ込みます。
  • ところが、Windowsでmergeしようとすると、新旧の名前が同時に存在できない(大文字小文字の違いだけ)ので、conflictが起こるわけです。
  • これはmercurialでは既知の問題点で、case foldingと呼んでるらしい。フツーの英語でした。

http://mercurial.selenic.com/wiki/CaseFolding
http://mercurial.selenic.com/wiki/CaseFoldingPlan
http://mercurial.selenic.com/wiki/FixingCaseCollisions

エクステンションでどうにかしようという試みもあるようですが、小生が同僚に試してもらった限りではうまくはいきませんでした。自分で試してみる気力はありません。Windowsを愛してないので。

http://mercurial.selenic.com/wiki/FixcaseExtension
http://mercurial.selenic.com/wiki/CaseFoldExtension
http://mercurial.selenic.com/wiki/CasestopExtension

mercurial内部で、改名を追跡するような対策を施す。という線もありますが、今のリポジトリ構造だとやや困難っぽいです。仮にできたとして、リポジトリの互換性が無くなるでしょう。

一方、subversionは、ファイルのリネームを追跡するらしいので、一見うまく行きそうに見えます。だからと言って、数々のデメリット を呑んでまでsubversionに戻そう。とかいうのは本質的に間違ってます。プログラマなれば、「手段」のために「手段」を選んではいけません。だってリネームやらなきゃ済む話なんだから。もしくは、大文字小文字を区別できないような駄目OSは捨てるべき。

それじゃ済まないのが現場。やっちまったら仕方ありません。

本件の解決方法は、意外と簡単です。マージの対象のファイル群を、予めチェンジセット両者にcommitしておく。

例 defaultブランチに、casefoldブランチをマージする場合
  • hg up default
  • hg revert -r casefold ... # 改名後のファイルに強引に置き換える
  • hg commit -m "コンフリクト回避"
  • hg merge casefold
  • hg commit -m マージしますた

ただしこの作業中は、他の作業者のマージ等を止めさせる必要があります。元の木阿弥なので。中央リポジトリサーバで、case foldingを検出して、pushを断るような仕掛けをしたほうが良いかも知れません。

時刻:
ラベル: ,

2011年11月1日火曜日

mercurialのススメ、その後

mercurialのススメを書いてから、もう10ヶ月経ってますが、当時からするとだいぶmercurialも普及してきた感があります。グーグルの検索からも、数人来ますしね。

筆者の出稼ぎ先では、新規案件にようやくmercurialを使い始めました。幾つかの些細な反論＆反対がありましたが、この手の話は使うより慣れろです。

従業員のほぼ全員がWindowsなので(筆者はlinuxですが、従業員ではないので)、漢字ファイル名を使わないわけには行きません。結論としては

  • プログラマはmercurialで
  • 非プログラマはsubversionで

まあ問題の先送りですね。

非プログラマの成果物は、画像だったりEXCEL仕様書だったりで、どうやってもコンフリクトするので、multiple headのメリットは殆ど有りません。また漢字ファイル名を付けたがるので、これを辞めろというのはかなりの混乱があるだろうという配慮からです。

一方、プログラマは、英数字だけのファイル名にしてね。と徹底しており、それが可能です。

まあ大抵の部署で、こういう運用なら可能なのでは無いでしょうか。

出稼ぎ先ではバグトラックはredmineを昔から使ってました。mercurialでも標準で繋がりますが、リポジトリを1組しか設定できません。こういうのって古いんじゃね？結局mercurialだけを接続しました。

multiple headとpushは、最初はかなりの抵抗があったようです。当面は、トータスhgのpushのforceだけ何とか覚えてもらって、マージは後で考えることにしました。

もともと彼らの実装は、特定ソースのswitch/caseを皆でよってたかって書き足す運用なので、コンフリクトは免れません。subversionだったら簡単だったよという主張。こりゃ弱ったなと思いつつ、色々確認してみましたが、どうやらswitch/caseの増減は、mercurialは苦手なタイプの差分ってことらしい。筆者はそういう書き方をしたことがないので、困ったことがない。と言うわけです。

そりゅあお前ら書き方が悪いよ、という台詞を飲み込んで、当面は一人がマージをすることになった訳です。2週目以降は、徐々に他の作業者にも自分でマージしてもらうようにしました。

なんだかんだと3週間ほど経ちましたが、マージは完全に馴染んだと言ってよいでしょう。特にトラブルも不満も出てません。
時刻:
ラベル: ,

2010年12月26日日曜日

mercurialのススメ(2)

筆者は5年ほど前から
バージョン管理はmercurialで統一しました。
http://mercurial.selenic.com/
利用当初は0.6だったと思いますが、今や1.7.2。
あのGoogle Codeですら採用しています。

subversionを使ってる方々は、今すぐgit/mercurialに移行しましょう。

もちろん筆者としてはmercurialを勧める訳ですが

デメリットを先に言っておきましょう。
多分それだけです。
subversionの問題点の殆どが解消します。それがメリット。

  • 「サーバ」が要らない。ってサーバ機能を内包してる。windowsの人はtortoiseHG(http://tortoisehg.bitbucket.org/)で一発インストール。
  • リポジトリ通信が高速。同規模のプロジェクトで、subversionの数倍。
  • リポジトリ同期のプロトコルが豊富。しかも内蔵。httpd, ssh, 
  • ブランチ＆マージは半自動的。場合によってはほとんど人手を介さない。
  • 事実上、コンフリクトは起こらない。(マルチプルヘッド扱いになるので先送りできる)
オフィシャルサイトの情報もよくできてますが、
http://mercurial.selenic.com/wiki/JapaneseMercurial
日本語チートシート(アンチョコ)を作ってくれてる人が居たので、これを傍らにおけば、運用は容易でしょう。http://www.textdrop.net/doc/mercurial-cheat-sheet-ja/

bazaarが入ってないのは？
http://bazaar.canonical.com/en/
リポジトリ間同期をするときに、必ずマージをさせるのは
筆者的にはsubversionの反省点ですので。
あと、実際に色々試してみると、激遅い。なんなのコレ。

故に、比較的シンプルなmercurialをお勧めしています。
時刻:
ラベル: , ,

2010年8月27日金曜日

youtube-dl 日本語版

職業プログラマで、自宅あるいは会社のPCに、
linux入れてます、って変人は少なくないと思います。
いやそういう事にしてください。

linuxであれば、youtubeの動画の保存には、
当然youtube-dlを使ってますよね。
いやそういう事にしてください。
http://bitbucket.org/rg3/youtube-dl/wiki/Home

コマンドラインのダウンローダは数あれど、
ファイル名に、youtubeの動画idを付けてくれるのは意外と少ないです。
#動画のページタイトルからタイトルを作ってくれるのは当たり前。
デフォルトで、というべきか？

ところが、残念なことに、日本語のファイル名を作ってくれません。
日本語部分というか、黄色人種の国の文字がバッサリ落ちます。
まあ作者は英語圏の人っぽいので、まあ読めない文字でファイル作られても楽しくはないでしょう。

仕方がないので、個人的に日本語パッチ当てて使ってましたが、
bitbucketでは、他人のフンドシで相撲がとれる（fork）らしい。

それって。本家の人はどう思うんだろう？
そしたら居るわ居るわ派生バージョン。
http://bitbucket.org/rg3/youtube-dl/descendants

はい、forkさせていただきました。
https://bitbucket.org/kamawanu/youtube-dl-japanesefilename
mercurialだっつーのも活けてますね。
#gist/githubはあっちはあっちで使ってますが、gitには微妙に馴染めません。

と思っていたら、githubに引っ越しちゃってました。

やっぱりforkするわけですが

時刻:
ラベル: , ,

2010年8月8日日曜日

mercurialとsubversion file:の実行時間測定

出稼ぎ先で、subversionに悩まされてます。

悩んでいる理由はさて置き、とりあえず「遅い」です。
mercurialに慣れた筆者には、20倍は遅く感じます。

具体的に、どの程度遅いのか、測って見ました。

結論から言うと、subversionはローカルで動かしても、
mercurialの2〜3倍遅い。ということに成りそうです。

Cで書いてある筈のsubversionが
pythonで書いてあるmercurialより遅いってどうよ？

普通にベンチマークすると、真逆になる話ですね。

速度に影響するのは、実装言語じゃない。
データ構造とアルゴリズムであるという。
好例ですね。

/usr/bin/timeで簡単に測ってみると、
subversionは、sysの時間が長めに見えます。
disk IOがネックになってる？

カーネルソースは、バージョン管理の「具」としては、
上品な部類だと思います。
これで、巨大なバイナリやらも詰め込んだらどうなることやら。

linuxカーネル2.6.35のソース 66MB

tarの展開
real 1m2.495s
user 0m43.451s

hg init
hg add
real 0m9.517s
user 0m1.940s

hg commit
real 1m12.223s
user 0m54.771s
#更新数 33316

hg clone
real 0m44.199s
user 0m22.597s

svn import linux-2.6.35 file://*/SVFS -q
real 3m47.385s
user 1m7.488s
sys 0m26.194s

svn co file://$PWD/TEST-SVFS linux-co -q
real 2m13.232s
user 0m47.135s
sys 0m18.765s
時刻:
ラベル: , ,

2010年4月4日日曜日

ソースプログラムのバージョン管理 mercurial のススメ(1)

プログラムは、ソースを1文字でも変更すると、
それは別プログラムだ、という位(筆者が言ってるだけですが)
デリケートなものです。

しかし、別エントリでも何度となく申しているように、
人間は間違えるものなので、
修正を繰り返すうちに何時の間にか動かなくなったり、
一つのバグを修正したら、別の機能が動かなくなった、
と言うのも、残念ながら良くあることです。

何処を修正したのかすら思い出せない。のもあり得ます。
「今までで一番マシだった状態」まで遡るのが一番です。

ディレクトリ丸ごとコピーなんてやっては居ると思いますが、
それはバージョン管理ではありません。バックアップです。
そして大抵は、忘れた時に一大事が起こります。
文字通り、ゲームのセーブデータみたいなもんです。

バージョン管理は、やはり専用ツールを使うのが一番です。
今すぐダウンロードしましょう。

結論から言うと、mercurial系が最適です。
プラットフォームを選ばず、
インストーラ一発で全てが揃うからです。


mercurialの競合と言うかライバルとして、gitがよく挙がりますが、
Windowsで、となると、cygwin入れたり面倒臭そう。
「道具」を入れるのに苦労するのは本末転倒です。

普通にオープンソースというと、C/C++で書くのがフツーでしたが、
mercurialは9割以上がpythonなので、
プラットフォーム依存が非常に少ないのでしょう。
と言うかpython本体が頑張ったお陰。移植が簡単。
故に、Windows及びMacOS X用まであったりします。
そういうのって、オープンソースで有名なのは
eclipseとかfirefoxぐらいでしょうか。

筆者がmercurialを知ったのは5年ほど前ですが、
python恐るべし、と思ったものです。
#当時はPHPで仕事してました。

バージョン管理は、必須業務です。
一人でも、ファイル1個でも効果があります。
やらないのは色々無駄です。

本家サイトで、まさしくmercurial自身で、
mercurialのソースを管理している模様。
リポジトリブラウザ機能は、外部からでもイジらせてもらえます。
便利っぽいでしょう？

こっちの方が「便利さ」は解りやすいかな。
バージョン遷移のグラフ表示です。
上はツリーの便利さ(面白さ)を感じてもらうために派手な部分を選んでます。
最新版はこっち
http://selenic.com/repo/hg-stable/graph/

私はlinuxのコマンドラインベースでモリモリ使ってますが、
Windows用では、シェルエクステンションが有るので、
右クリックから使えます。
あー、でも、日本語化は遅れていたと思った。
#って言うか、プログラマなら英語に恐怖感を持っちゃ駄目です。

オフィシャルサイトでもガイドがありますが、
日本語紹介記事もアチコチにあります。
分散バージョン管理論の話まで行っちゃってるので、お得です。

知人に「リリース以前は、バージョン管理は要らない」なんて言ってる人が居ますが、
リリースバージョンと、ソースバージョンの話を混同してますね。
そうだと思いたい。

バージョン管理は、基本的には「今までで一番マシだった状態」な状態を
段階的に記録していくものです。段階は、細かければ細かいほど良いです。

別の派生バージョンに修正を適用したり、がやりやすくなります。

ちなみに、リリースバージョンは、タグ ブランチ として管理すると良いです。

時刻:
ラベル: , ,
登録: 投稿 (Atom)