git-svn 作業フロー
plagger レポジトリで作業するとする。svkとの比較つき。
まず git レポジトリ作成
git svn init -s http://svn.bulknews.net/repos/plagger/ plagger
これで、plaggerってディレクトリにgitレポジトリができる。svk mirror的なものですね
次にsvnとデータをsyncさせる。
cd plagger
git svn fetch
これは svk sync 的なもので対象の変更をすべてtrackしてmerge情報とかを記録する。なので重い。体感では svk sync 以上。
ちなみに最初の init の代わりに clone とすると一気に fetch までしてくれる。
trunk で作業するよ (ここからが通常のワークフロー)
git checkout trunk
で trunk に移動。
svn が変更されてるかもしれないので
git svn rebase
でチェック。(svk pull 的なもの)
いろいろ編集後
git commit -a
で git レポジトリにコミット。この時点ではローカルの git レポジトリにしか反映されてない。
svn に反映させるには
git svn dcommit
とする。これが svk push 的なもの。
ここまでが一応 co から ci までの流れ。
もう少し例。
fastladder-crawler ブランチで作業してみる
ブランチに移動
git checkout fastladder-crawler
いろいろ変更後コミット
git commit -a
このブランチをtrunkにマージしよう
まずtrunkに移動して
git checkout trunk
マージ
git merge fastladder-crawler
これだけ。すばらしく簡単。
ローカルブランチを作って作業も簡単
まずtrunkのローカルブランチをつくる。まずtrunkへ移動
git checkout trunk
test という名前のブランチ作成してそこに移動
git branch test
git checkout test
これは以下で一発にできる
git checkout -b test
いろいろ編集して test ブランチにコミット
git commit -a
それを trunk に反映
git checkout trunk
git merge test
用が済んだらtestブランチ削除
git merge -d test
とかいう感じ。
ブランチ作ったりマージしたりがさくさくできて気持ちいい。svk ユーザーは一度さわってみるといいと思う。
zsh の prompt に git のブランチ情報を表示
svk でやってたものの git 版。
ref: refs/heads/ という部分を消していいのか、ほかのものが入る場合があるのかよくわからなかったので全表示している。
まぁぱっと見で git とわかるからいいかということでとりあえず。
codereposにあげてあるよ。
あぁ、なんか ref: とかすらでずに sha-1 ハッシュ値だけのときもある。もう少し調べないとだめだ。
git
cho45 さんがイイヨイイヨいっていたので git & git-svn ちょっと試し中。
大体基本的な使い方はわかった。
マージが簡単なのはほんとにいい。svk の smerge がより簡単になった感じだ。
ブランチの処理もsvkよりこっちのほうが好き。作りまくって、マージしたら消す。
まだわからないのは適当な場所で git init してスクラッチ的にプロジェクトつくったときそれを svn のほうにマージするにはどうしたらいいのかがまだわからない。
git-svn なレポジトリからスクラッチのほうを pull すればいいのかな？ あとでためそう。
あと svk とちがって zsh の補完がかなり高機能でうれしい。svk のはほとんどないも同然。(あるけど遅いので使ってない)
もうしばらく使ってみてから使うかどうか決める。
utf8::is_utf8
miyagawaさんが#catalystでいってたことやっと理解できた、きがする。
use Data::Dumper;
my $s = "H\x{c3}\x{ab}llo";
utf8::decode($s);
warn Dumper $s; # => "H\x{eb}llo"
warn utf8::is_utf8($s) # => 1
だけれども
my $s = "H\x{eb}llo";
warn utf8::is_utf8($s) # => Warning: something's wrong
ということで、"\x{6751}\x{702c}\x{5927}\x{8f14}" などというData::Dumper表記でかならずしも utf-8フラグがたつわけじゃない。ということがいいたかったんだと思うのだけれど、
そもそも ë が latin-1 では "\x{eb}" だけど utf-8 では "\x{c4}\x{ab}" であるということを僕が認識してなかったせいでおかしなことになった。すみません。
Catalyst::Controller::Resources
かっこいい。
オレオレ規約をもとに雛形を生成するヘルパースクリプトでがんばるよりこういう自分用のコントローラをつくるほうがスマートだなぁ。
Catalystユーザー的にはオールドタイプな自分としては見習おうと思った。
OpenFL + Plagger::Plugin::Store::Fastladderも実戦投入した！
といっても今まで使ってたyamlに - module: Store::Fastladder の項目を追加しただけだけど。
今までの Store::DBIC (PlaggerLDR) のも残してあるので今はどちらも使える状態。
ちなみに使用感は PlaggerLDR とほとんど同じだなぁ。グリモンなくても使えたりするのが Store::Fastladder のほうがいいところだけど、いますぐ PlaggerLDR から乗り換えるメリットはあまりないのかも。(PlaggerLDR使ってる人はね)
PlaggerLDRよくわからんくてつかってないけど、使いたかったというような人にはかなりおすすめだ。動作している OpenFL の環境があれば Store::Fastladder は plagger の yaml にそのデータベース情報を書くだけで動作する。
あと、OpenFL のデータベースは SQLite じゃなくて mysql を使ってる。PlaggerLDR で経験したのだが、SQLite だとフィード増えてくるとかなり重くなる。せいぜい数ヶ月が限度。
ユニークなランダム文字列
すでに生成したIDかどうかを気にする必要がないユニークな文字列を作成しようとした場合
use Data::UUID;
use MIME::Base64::URLSafe;
print urlsafe_b64encode( Data::UUID->new->create );
こんな感じにやるのがいいのかなぁ。これで22文字。
んー。
エントリーのURLとかにつかいたくてもう少し短くしたいけど、文字列生成したときに重複してないか調べるためにDBを引くというのがイヤダナー。
plaggerをfastladderのクローラーとして使う
のを作ってみた。
やっとPlaggerLDRいらずになるかなー。
まだDBのカラムの役割とかよくわかってなくて適当な値いれてたりするとこあります。
クローラー動かすのに
sudo gem install rfeedfinder
も必要だった。
あれクローラーじゃなくてfeedをsubscribeするときに必要だったのかも。覚えてないけどとりあえず必要。