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

2012年11月5日月曜日

rhodecode1.4.4を試してみた #tokyomercurial

世の中GithubEnterpriseでpullrequest方式での開発が
一部では標準化しているんじゃないかと思われる今日この頃いかがお過ごしでしょうか?

とは言うものの、いくら有用性を語ってもそうそう導入されるような世界じゃないですよね?高いし。
せめてGithub/Bitbucketの有料アカウントを…と思ってもそれもねぇ…って世界ですよね(´;ω;`)

そんな僕達がPullRequest方式で開発したい!!そうだRhodeCodeがあるじゃないか!!
という私やあなたみたいな方にお届けするエントリーですw

あ、ちなみに件名に#tokyomercurial を追記した理由は特にありません。
あえていうなら、このツイートがあったので…ぐらいかな?



あ、ちなみに長いのでご注意ください


試した環境はこんな感じ

  • CentOS6.3 64bit minimal状態から
  • VirtualBox上で

すげー大雑把にやりますので、必要な部分は適宜脳内補完でお願いします

実験用なのでselinux/iptablesは無視

最初は…
とりあえず入れましょう。
使わないのもあるけど。


python周り入れましょう。
最初から入っているのは2.6系のはずですし、別にそのまま使ってもいいですが…
pythonbrewという流行りに乗っかっておきましょう。
→ それだったら pythonz で入れろって話しなんでしたっけ?
下記はちょっと時間かかるので、コーヒでも入れましょう。


おまたせ、rhodecodeです。時間かかります。
なぜならいっぱい一緒に入りますから。当然Mercurialもこの時入りますので。
さっき作ったコーヒでも飲みましょう。


使用するwebサーバでも入れましょう。
rhodecodeのドキュメントにはapacheとnginxのサンプル設定が乗ってますので、テキトーに。
ここではnginx入れます





さて、rhodecodeの設定をやりましょう。
まあrhodecodeのドキュメントままといえばそれまでですが…



これで設定ファイルができたので…試しに動かしてみます


ブラウザで確認するとこうなっているかと。
/etc/hosts にvm2って名前で仮想マシンのip書いているのでurlはそんな感じ


さっき作ったadminユーザでログインしてみます

とりあえず3名ほどユーザを追加してみましょう
まあLDAPが使えれば、こんなこといらないんだろうけど…
Admin > Users > Add New User




時にログイン画面の下に小さくDon't have an account? という項目ありますが、
こちらから誰でもアカウント作成が可能です。
が、こちらで作ると初期の状態だとログイン出来ません。
 管理者にActiveにしてもらう必要性があります。


 各自が作成した時に最初からActiveにするためには
Adminユーザで
Admin > permissions で Registration を変更すればいけます。


次にとりあえずAdminユーザでrepository groupを作っておきます。
実際に仕事で使う…とかになると、プロジェクト単位で切ることになるのかな?
もちろん作らなくてもOKですが、とりあえず。

Admin > repositories groups > ADD NEW GROUP


作ったらパーミッションを設定します。
ここでは太郎くんにadmin権限を渡してみます。


さて、太郎くんでログインしてテキトーに作ります

ご丁寧にQuick Start ってありますね。



この通りやってみましょう。


結果

当然反映してますね。

続いて二郎くんでフォークしてプルリクエストを出してみます。
まず二郎くんでログイン
そしてhellorepoを選択し OptionsからForkを選びます

すると、repositoryを作成した時のような画面になります。

Fork結果

fork-hellorepo-jiroの詳細を見てみるとClone urlってありますね。

手元にcloneして作業してみます。


作業に満足したらプルリクエストしましょう
Options > Open new pull request を選択します



結果こんな感じ


ソースにコメントも可


実際にレビューした結果を選択
change status にチェックを入れて、レビュー結果OKかどうか選択しましょう。

全員がレビューしたと仮定


あとは誰かがComment and closeを押せばいいわけですが…
現状で自動でこのリクエストは取り込まれない…よね?
→間違っていたらご指摘ください。
なので手動で太郎くんがpullしてマージしてpushすることになります。


うーん、メンドイ。
何よりせっかくApproved とフラグをつけた内容なのに、結局fork元repository上では当然それがなくなっているわけで…
更にPullRequestを取り込んだからといって、PullRequestが閉じられるわけでもない。
→ Forkしたrepositoryを閉じれば(削除すれば)消えます。
もっというと手動で取り込む=結局approved/reject関係なく取り込む人次第なので、
このへんは運用ルールでどうにかするしか無さそうです。

ちなみに上記はbranch切ってやりましたが、別にbookmarkでもいけます

その辺も運用ルール次第なのかな?

ただBitbucketみたいに、「こう言うふうにコマンド叩いて取り込めるよ!!」とかの表記がないので、
リビジョン指定よりもブランチ/ブックマークで取り込むことを前提とした運用のほうが無難だと思います。


多分gitでもそんなに操作変わらんだろう
ということで次。

まずnginxを使ってアクセスできるようにしましょう

ってもドキュメントのサンプルから大きく逸脱しなければ大丈夫なはずです


あくまで動作確認なので自分は本当にほぼ上記ドキュメントのまま。



このあと service nginx start で ipaddressであたりにいけるはずです


clone url もport番号がなくなったのが確認できるはず。

なおこの段階で、rhodecodeの設定ファイルであるproduction.iniのhostを「127.0.0.1」に直しても問題ありません。
nginxで飛ばすわけだしね。
むしろしたほうが、ipaddress:5000でアクセスできなくなるし、いいんじゃまいか。

ただし
full_stack = false
にすると、repositoryをcloneする際にこの症状にハマります。
まあ httpのままでなければいいのかもしれないけど…

また
static_files = false
にすると、自分の場合web表示が崩れました。



あとはサービス化
このあたりを参考にしました
きっとこんなのを作ればいいんだろう…




シェルスクリプトとか詳しくないし、このへんはそんなに突っ込まないでほしいw

あとは
chkconfig rhodecode on
で登録しておけばOKですね。

とりあえずこれで「最低限」使うことは可能になると思います。
ローカル内でしかアクセスされないなら、まあセキュリティとかそこまで考えなくてもいいでしょうし、
レビューツールとしてはありだと思います。

ただ、その他のツールと連携していくこととか考えたらここでAPI見てなんか書いたり、
もしくはincoming hook書いて直接repoの中においてきたり…とかになるんでしょうか。

rhodecodeを使うとなると、issue trackerを外部に依存することになるでしょうし、
それ+CIサーバと連携…とか考えると、ちょっとめんどいですね。
個人でやる分には多少失敗しようがそれなりに動けばいいんですけど…ってか
個人だったらGithub/Bitbucketで事足りるし、ウムム…
この手の構築が好きで得意な人がいるような会社だったら、検討の余地は十分あると思います。

そういえばLDAP連携で @usaturnさんが悩んでいた記憶が…



つまり @usaturnさんがrhodecodeを使った素晴らしい開発環境構築を年内にまとめてくれるはず…!?


Admin > Settings に hgsubversion extension を設定できる箇所が有りました。
これにチェックを入れたら、最初にrepository作るときのclone先にsvnのrepositoryを指定できるかも?




補足 会社でrhodecode使い始めました。
Gitに関して追加設定が必要だったり、HGで日本語コメントがちゃんとrhodecode上で表示されるようにしたり…
みたいな設定をお隣の席の人がやってくれました
詳細は以下
http://htn.to/TAKNVB




2012年5月6日日曜日

bitbucketで一人pullrequestとかしてた

bitbucketで遊んでみた

ちなみにGW中bitbucketとずっと戯れていたわけじゃないよ。猫と戯れていただけだよ(´;ω;`)

bitbucket は自分のリポジトリをforkできます。
→確か前々回ぐらいの #TokyoMercurial で @troter さんがそんなことを呟いていましたが、確かにできましたw
githubはしらん。

まあ、普通しないよね。練習以外に何に使うのだろう…

あとpull request そのものについて詳しい訳じゃないので間違っている場合はご指摘ください。
名前からして「ねー、ねー。僕のリポジトリ(ブランチ)pullしてよ〜」なんですよね。



準備

とりあえず適当にリポジトリを作ります

作ったらテキトーにコミットしてpushしておきます

bitbucketに戻ってforkしてみます


普通他の人からforkするときはリポジトリ名はそのままでしょうけど、自分で自分のリポジトリをforkするので名前は変えたほうがいいと思います。

fork結果を見るとこんな感じで、何をforkしたのかという情報とかがオリジナルと違う点のようです。

compare fork というのを選ぶと、hg in/out を実行した結果が見られます。
作ったばっかりなので当然差分はありません。



とりあえずdefaultブランチのままぶん投げてみる

forkした側を適当に修正して、pull requestをしてみます

自分のどのブランチを相手のどのブランチに送り込むのか選択する感じ?

compare forkを見てみたところ
さっきと違ってoriginalとの差分がわかります

pull requestを受け取った側

とりあえず受け入れてみる

フツーにpullした状態が出来ます。

調子に乗って2個コミットした状態でRequestを投げてみます

compare fork だと hg diff -r b68e677f670d とやったような感じ
(2個分まとめての差分)

受け入れた結果。
何も問題なさそうです。



拒否ってみる(拒否られてみる)

テキトーにコミットしてpull Requestしてそれを拒否ってみました

Rejectボタンを押すとこんな画面で、拒否理由を書いてRejectするようです

拒否完了


じゃあ、肝心の拒否られた側ですが…
どうやらInboxにメールが届いているだけで、視覚的にダメだったお!みたいなのはなさそうです。
まあ受け入れられたときもそんな感じですが。
俺が気がついていないだけでもっと視覚的な何かがあるんでしょうか?

ところで拒否られたらどうすればいいんでしょう?
個人的にはstripしてなかったことにしてしまえばいいかと。
もしくは再度forkすればいいんじゃね?


backoutがいいんじゃね?的なこと書いてありますが、forkしたリポジトリが複数人でガンガンコミットしたり…
ってことは無いでしょうし。わかんないけど。
あとこの作業後にbackupファイルがDL出来るみたいです。

ローカル側はまあ適当に直せますしね。



下図みたいにpull requestしようとしたら元側が更新されていた…みたいな場合
まあrebaseしろって話でしょうけど、やってみる



受け入れ側…よく見たら「Accept and merge」になっている…
ということはマージして受け入れるんだろうなぁ

押してみたらコミットメッセージが書けるようになっていた



結果 まあ当然の結果



pull requestを受け入れてもらったわけですが、当然下記のように元リポジトリとfork側で違う歴史になりました
揃えないといけませんがどーしましょう


別にfork側のリポジトリを消して再度forkしてもいいと思いますが、改めてcompareを見てみるとコマンド書いてます。
ので、このまま実行してみます。


cd fork_repo_path
hg pull -r default ssh://hg@bitbucket.org/orginal/orginal_repo
hg update default

hg serve でローカルの状態見てみるとこんな感じになる。
これでfork側がoriginal側を追従できた

あとはpushしてやればOK



ていうかpull requestを取り込むかどうか、ローカルで確認したいんですけど!という受け入れ側(original側)はどうすれば?
というのも実質さっきのやつと一緒

forkした側で見れるcompareのoutgoingに書いてある通りに実行でいいんじゃね


# オリジナル側 forkした側じゃないよ
cd orignal_repo_path
hg pull -r default ssh://hg@bitbucket.org/fork/fork_repo

上記みたいにpull requestしてきた人のデータを直接pullすればローカルでじっくり確認できます。

ちなみにこのrequest結果をローカルでみて、
「いけるいける!!」
と思いオリジナル側がこのままpushしたらどうなるのか…

なんと、受け入れた事になりました!
ちゃんと受け入れたよ!ってメッセージも発行しているし、さすが。





正直ここまで来たらもう先は読めたしやらんでもいい気がするけど、ブランチ切ってpull request も試してみる。
一応下記を試す
すべてRequest側はhogeブランチを切るとして

  • hogeブランチをdefaultに取り込んでもらえるかどうか
  • hogeブランチをhogeブランチとして取り込んでもらえるかどうか

というわけで一つ目。
まあこんな感じでsend requestを投げた



requestを投げた側なんだけど、compare forkに差分表示が無い…
なにかしら表示してくれると思ったんだけど、もしかしてdefault ブランチのみを追従しているのかな?
(だからcompare に表示されるコマンドが -r オプションつけているかも…?)

受け入れる側も差分とかは出るものの、ブランチ切られているってことは
ローカルで確認しようとした時にヤヤコシイよね。
ブランチ名指定しなかったら下手したら腐るほどデータ引っ張ってきちゃうし。

まあとりあえず受け入れて…と思ったら、これはAccept and pull なのか。へ~


っておい、やっぱりマージじゃねーかorz


でもまあpull request的に
「hogeブランチだけどdefaultに取り込んでね!」
って明示してんだから動作的には正しいですよね。

でもマージ時のコミットメッセージ書けなかった…


次、hogeブランチとして取り込んで!!!




フツーにpullして終わりました。めでたしめでたし





pull requestの内容が競合するようなものだったらどうなるのか

いやまあ正直requestする側がrebaseしてくれれば…ね… ってのもあると思うんですけど
pull requestと本家の更新が同時とかってこともあるだろうし、試さずにはいられない

compare forkを見る。もうおもいっきりコンフリクトって書いてある、赤字でw



それでも気にしないで送りつける



受け取った側。
コンフリクトしてるから取り込むなら自分で解消してねってところですかね。


送り手的にはcomapreで事前にコンフリクトがわかるわけですし、やっぱり解消した上で送ったほうがいいとは思います。
けどまあ送ることはできるということで。



競合した上にブランチ切ってあったらどうなるのか?
ブランチ切るとそれはcompareとして表示されなかったので、一見コンフリクトと見なされないのではないか?
(いやもちろんfork側がincomingを見て、差分があったら取り込んだ上でpushすればいいんだけど)

試してみると… なんだちゃんとコンフリクトって出ますね。




わたしoriginal側だけどforkした奴が素敵だから勝手に取り込みたいの!

pull request 出してくれているわけじゃないけど、いい修正だし欲しいなぁ…
みたいなとき

実際そんなパターンがあるのか?と思いますが、あったんですよこれが。

まあ、pull requestを取り込むかどうかローカルで確認したい時と同じでいいハズ
そして今更気がついたけど、コミットする人の名前変えればわかり易かった…


こんな状態で
cd original_repo_path
hg pull -r default ssh://hg@bitbucket.org/fork/fork_repo
#取り込むか確認したら
hg push

で、こうなる。



じゃあ開始時点がこんなだったらどうするか?


まあ諦めてマージな気がするなぁ

とりあえずpullして持ってきた状態


まずマージしてみる

至って普通


続いてrebaseなんだけど…そもそもこの場合ってrebaseは間違っている気がするんだなぁ…
なぜならpullして持ってきた状態って全部のphaseがpublicなので基本rebaseしない前提のはず…

まあでもやってみます

pullして持ってきた方を自分にくっつけることにした場合

cd original_repo_path
hg phase -d -f tip
hg rebase -d 9 -s tip
hg push

結果
一直線になっているし問題なさそうだけど、リビジョン番号が変わってしまうことに注意
まあそれ自体は別にわかりきっていることですが…

それよりもfork側のcompare forkから incomingを見るとこうなる

もちろんoutgoingもある

うーん、びみょー


逆版(自分のcommitをpullして持ってきたcommitにつなげる)ってのはもっとやらない気がする。
だってoriginal側を変更するということはstripしないと見た目おかしくなるし、
何より見ている人、触っている人がそれなりに居るだろうからまずやらないよね?

なので省略


有りなのかどうなのかわかりませんが、マージはしたくないけど取り込みたいし…の場合
「やあやあ、そのコミット リベースした上でpull requestしてくれないか!」と連絡するのが一番よかったりして…


色々とやってみたけど結局どうpull requestするのがいいんだろう?

GitHub的にはこちらのブログを見ると(pull request マナー でググってtopだった)
pull request用のブランチ切ってrebaseしてまとめてそれを投げるのが良いらしい。なるほど。

じゃあbitbucketというかhgの場合は…

適当に幾つか見て回りましたが、ほぼ default -> default だったので
特段pull request用にブランチ等は意識しなくて良いようです。多分。

なので pull request 前にoriginal側との差分を最小限にして(取り込んでrebaseして)から
やればまあいいんじゃないかなぁ…

手順的には

  • forkする
  • 作業する
  • original側をpullしてくる
  • 更新があったらrebase
  • push
  • pull request

みたいな手順になるんでしょうね。きっと。

何れにしても自分で自分のリポジトリをforkできるんで色々と試しておくといいのかもしれません。

あとは実際にpull requestしてダメだったら駄目出ししてくれるはず(他力本願

ついでに言うと #TokyoMercurial に参加すると誰かがやさしく教えてくれるかもしれない?(ステマ