- ページ: BugTrack2
- 投稿者: henoheno
- 優先順位: 普通
- 状態: 完了
- カテゴリー: 本体新機能
- 投稿日: 2005-02-09 (水) 23:08:01
- バージョン:
メッセージ†
ここのところ継続的に改良案(パッチ)を出し続け、ヒットも多く出しているteananさんの、SourceForgeアカウントにコミット権を与え、今後自由にPukiWikiのこそばゆい点を改良していただく事について、昨日ご本人に相談してみました。
早速良い返事が返ってきましたたので、ちょっと皆さんに告知期間を置いてから、実行しようと思っています。
まずは練習用のCVSリポジトリを作ったり、クライアント環境(デバッガ含む?)をセットアップしたり、コミットログやコードに使う文字コードなどの打ち合わせなどから。
- 新機能のteananです。不束者ですがよろしくお願いいたします。ちなみに、多少、評価されすぎなような気がしますので、ちょっと心配だったり (^^; -- teanan
- 素晴らしい。 次回リリース(?)の目玉ですね :) -- にぶんのに
- いえ、全身ですから。 -- henoheno
- いや、本体に組み込むのですからやっぱり目玉です。とかって。 --
- 確かに目の周辺にスペースがありますけれど、あれは発光時の熱を逃すための・・・・・・・・・何の話でしたっけ? -- henoheno
作業環境の整備: デバッガ†
- とりあえずデバッガは何を使いますか、あるいは既に使っていますか? 私は時間を節約したかったので(※PHPシロートですから)、メンテナ就任記念にZendStudioを購入して、最初からそれ*1しか使っていない状態ですが、TruStudio とか xdebugとか、他の手段が無いではありません。もし未決定であればご検討ください。 -- henoheno
- どうしてまだデバッガ関係の話題がまとまっていないのかな・・・ (^^; -- henoheno
- 現状はデバッガをつかっていません。ZendStudioを購入するのはちょっと厳しい*2ので、他のデバッガを試用してみます。 -- teanan
- (ついでにデバッガ周りの情報がdevサイトに充実してくれるとうれしい :) ) -- henoheno
- 何気にechoとかprint_rでまにあってるって人が一番多いような気がしてますが… (^^;; -- ishii
- あとは、javaのlog4jもどきを独自に実装して使ったりとか… -- ishii
- 今のところechoで間に合ってます (^^; -- teanan
作業環境の整備: CVSクライアント†
- CVSの本は何か最低一冊、お手元にあった方がいいですー -- henoheno
- CVSリポジトリにsandboxモジュールを作りました。本文およびコミットログの文字コードの確認、ブランチワークの練習など、自由にお使いください。 -- henoheno
- お奨めのCVSの本はありますか? -- teanan
- 本じゃないけど、とりあえずこの辺は読んでおいた方がよさげ… -- ishii
- バージョン管理システム CVS を使う
- http://radiofly.to/nishi/cvs/
- CVS--Concurrent Versions System (in japanese)
- http://www.cyber.sccs.chukyo-u.ac.jp/~kin/help/cvs-jp/cvs-jp_toc.html
- あとは、ローカルで弄り倒すのが一番じゃないかなぁ…なんてな… :) -- ishii
- なるほど、参考にさせていただきます。ありがとうございます。 :) -- teanan
- 日本語で書いてあるCVS専門の本というのは数少ないので、選ぶというよりどっちにするかというレベルの問題です (^^; 私は「CVS ‐ CVSによるオープンソース開発」から入りました。他にはみかままさんのCVS本があります。他には? ・・・とりあえずCVSNTの本は違う世界の話として無視して構いません。*3 -- henoheno
- そうですね、ローカルでいじり倒すのは私もおすすめします。その時にも、手元に一冊はあった方がいいと思いますです。 -- henoheno
- 久しぶりに書店をチェックしてみました。オライリーの「実用CVS」が出たのを忘れていました。また、「CVS・WinCVSハンドブック」という書籍も出ていました。 -- henoheno
(準備) Sourceforge.jp へいざコミット†
- 6. コンパイルファームとシェルサーバに関する文書
- さて、既にteananさんのアカウントにはコミット権があります。また、PukiWiki 1.4.5_1 のリリースも一段落しましたので、まずはSouceforge.jpのドキュメントなどをチェック戴いて、実際にcvs:../sandbox以下を対象に、適当にいじってみて下さい。 -- henoheno
- pukiwikiモジュール(PukiWikiのソース本体)の中をいじるとメールが飛びますが、sandboxやdevelモジュールの場合はメールは飛びません。ChangeLogもpukiwikiモジュールだけが対象になっています(いずれそれぞれ用意しても良いですね)。 -- henoheno
- 気をつけるべきは文字コードと改行コードなので、sandboxの中でわざと、日本語のコミットログで何かコミットしてみて下さい。EUC-JP/LFでコミットできているかどうかは cvs log などを見ればわかります。 -- henoheno
- お、早いですね :) Sourceforge.jp のドキュメントへのリンクをここに貼ろうかと思っていたのですが不要そうですね -- henoheno
- sandboxにファイルを足して置きました。cvs add ができない件とは別に、これをターゲットにいじれると思います(そうするともう少し状況がわかるかも)。 -- henoheno
- ちなみに、sshの公開鍵をSourceforge.jpに登録してありますか? anonymous pserver だとcvs add もcommitもできません。コミッタ－が用いる方式(ext)は cvs login コマンドを使う必要がないので、このあたりの話かもしれません -- henoheno
- ssh周りがセットアップできていない場合、まずはsshクライアントで shell.sourceforge.jp にログインできる状況を目指して下さい。そこまで行けばもうすぐです。Windows環境でセットアップする場合、例えばcygwinに付属している opensshパッケージのssh.exe を組み合わせられます(私はCVSごった煮版のcvs.exeを愛用していますので、cygwinのcvsパッケージは入れていません) -- henoheno
- ここでCygwinの…と言うのならば、全てCygwin内で完結したほうがよさげ…*4 -- ishii
- cygwin の cvs パッケージは、勘違いでなければ&状況が変わっていなければ、コミットログの日本語文字コード・改行コード変換まではしてくれないんですよ。つまりPC-Unix環境でcvsをいじる人や、同じ人がPC-Unix環境で同じソースをいじる時に不都合が出ます-- henoheno
- ああっ、私の場合はinetd経由でlocalhostにteratermでtelnetして export EDITOR=vim でEUC/LFな環境で作業しています。文字コードや改行コードはvimで好きなように設定できるので、わざわざごった煮版は使う必要が無かったりします。でもまぁ、これは選択肢の一つでしかないので実際に作業をするteananさんに、今どのような環境で作業をしているのか聞かないことには、適切なアドバイスは出来ませんねぇ…。そういえば、聞いた所によるとeclipseにはsshとcvsクライアント機能も有るようなことを聞いたことがありますし…。 -- ishii
- ふむふむ。私も普段PukiWikiのソースはFreeBSDにTera Term + TTSSHでログインしてEUC/LFな環境で作業していますから、今ごった煮版を使っているのはWindows環境上の一部のデータだけです。今回のポイントは作業対象がEUC/LFの世界であるため、どのプラットフォームでもそれなりにcvsが使えますよということです :) -- henoheno
- (cygwin cvsとかを使いたい場合) コミットログの文字コードの問題については、今PukiWikiでやっているように、コミットログを基本的に英語で書くようにすれば回避できます。ただし既存の日本語コミットログはどうしようもないので化ける可能性があります。改行コード変換を素のWindows版cvsクライアントがしてくれたかどうかはもう記憶に自身がありませんので、試してみた方がいいです -- henoheno
- CVSのクライアントは、WinCVSごった煮版を使っています&使いたいと思っています。他の環境も構築できないことはないですけど、慣れた環境が一番ということで・・・ -- teanan
- ここに細かく説明していただいているので、非常に助かります。このページは私*5のマニュアルとなるでしょうから、出来る限りたくさん助言していただけると嬉しいです :D -- teanan
- WindowsのGUIにべったりならば、WinCVSごった煮版＋Puttyってパターンが一番多い気がするのでその辺をgoogle先生に聞いてみるとよさげ… -- ishii
- はい、まさにその環境で構築しています。 -- teanan
- http://rumble-jp.sourceforge.jp/putty-howto/putty-doc.html あっ、もろに書いてあった。 -- ishii
- sshの使用できる作業環境が複数個ある場合、それぞれの公開鍵をSourceforge.jpに登録しておけば便利です。ソースをいじる以外に、sshログイン環境はWebスペースをメンテナンスする際にも使いますので。もちろん、複数のマシンでPukiWikiのソースをいじっても問題ありません(問題が無ければ)。ssh公開鍵+暗号鍵のセットを複数の場所にコピーしまくるのか(※それぞれのssh環境がソレを取り扱えないならばこの手は使えない)、環境ごとに作成するのかは任意ですが私は環境ごとに作る様にしています。 -- henoheno
- ishiiさんにご紹介いただいたページが参考になりました。WinCVSの使用するrshでputty/plinkを指定するのがミソでした。 -- teanan
- ひょっとして CVS_RSH 環境変数のことですね :) -- henoheno
- WinCVSに「使用するrshを指定」する、という設定項目がありました。ここにplinkをフルパスで指定しました。 -- teanan
チェックリスト (DONE)†
- DONE
- cvs:../sandbox モジュールを作る
- PukiWiki-cvs メーリングリストにteananさんのコミットが飛ぶようにする
- pukiwikiプロジェクトにアカウントを追加する
- PukiWiki-announceにてアナウンス
- sandboxにテスト用のデータを置く (chmod a-x hoge.php && cvs add hoge.php && cvs ci -m "" hoge.php)
作業環境のセットアップ進捗†
- ログインとcheckoutまではコード0を確認しました。現在、ファイルの追加ができなくて調べていますが、もう少し時間ができましたらリトライします。 -- teanan
- shell.sourceforge.jpへのログインができました。クライアントはputtyjpです。 -- teanan
- 後はcvsクライアントからsshクライアントを呼び出すあたりの確認ですねー :) -- henoheno
- チェックアウトおよびコミットができたようです。ログはEUCになってるようなきがします。改行コードについては検証中。 -- teanan
- これで cvs checkout or cvs up -dP => 修正 => デバッグ => (随時cvs up) => cvs diff -u => cvs ci -m "log" といった流れが同じ環境の上に整ったでせうか。であれば環境のセットアップはひとまず完了ですね ;) -- henoheno
「こそばゆい点」の定義について†
- どのような基準で手を下したら良いでしょうか? -- teanan
- 今までteananさんがorgサイトなどで作ってきたパッチ類*7を取り込めないかどうか、BugTrackを(1本)立てて、順次見直してみるとかどうでしょう。このページみたいなノリで。毎回お題を挙げれば、コメントが随時回りから入ると思います。 -- henoheno
- そうしているうちに、またリアルにカユイ部分が出てくると思います :) -- henoheno
作業領域の連絡等†
- ちなみに、どのBugTrackに手をつけているか、どのように検討されているか、修正方針等の意識合わせはどのようにいたしましょうか?*8 -- teanan
- そうですね。私だと普段開発日記で「検討ほか -- henoheno」として日頃検討中の(検討していた)項目を挙げたりしています。また、CVSにコミットすることが明確な日は、先行して「CVS更新予定 -- henoheno」という題でメッセージを載せています。こんな感じでいかがですか? -- henoheno
- でも、今動けるのは二人ですし、そんなに気張らなくても大丈夫です。基本的に元に戻せますし、該当するBugTrackを読めばいいしコミットメールも届きますし。 -- henoheno
- 外部要素としては、trackerプラグインやattachプラグインはは外部に改造版や最新版がありますので、極力手を付けない様にしています。 -- henoheno
- ちなみに私の今今の関心事は pukiwiki.ini.php の日本語版を用意することや、パスワードをmd5/sha1/cleartextなどマルチ対応にすることや、tDiaryスキンのCSSのバリエーションを増やすために全テーマを再チェックして色の傾向を割り出して5～6タイプ程度実装して、そのノウハウをPukiWikiのデフォルトcssを多色化する方向に持っていったり、codeプラグインのライセンス関係を再確認しようとしたり、各言語に特化したコンテンツを管理するためのCVSモジュールを別途作ることを検討するような話の中から、今の空き時間の中で出来る事を少しづつ進めることです。 -- henoheno
- 了解しました。とりあえず、私がやろうとしていることとhenohenoさんが検討されていることは重なっていないようですので、効率的に動けるのかもしれません :) -- teanan
(2005-04)
「タグ」とは、特定のリビジョンにつけることができる名前(tag = 荷札)です。CVSの場合ファイル単位にリビジョンを管理するため、ソースツリーの「一段落したある状態」を指し示するために「特定のリビジョン番号(例えばr1.5)」を使うことはできません。最新のリビジョン番号が、それぞれのファイルごとに異なるからです。その代わりに、それぞれに同じタグを打っておけば、タグを指定するだけで任意の状態を取り扱える(取り出したり、マージの基準にする事ができる)様になるわけです。
良く使われるのが、ファイルをリリースする際に、リリースするファイルと同一の内容が取り出せるようにタグを打つ「リリースタグ」です。(実際の手順としては、タグを打ってから、そのタグで取り出したファイルをリリースすることになります)こうしておくと、パッケージ作成処理を自動化できたり、パッケージをいつでも再生成できたり、特定のリリース間の比較や、特定のリリースの取得が簡単にできる様になります。
打ったタグは、後で動かす事も削除する事もできます。「特定のタグでチェックアウトした対象に別のタグを打ってから、元のタグを削除」すればタグの名前を変更した事になります。
[注意]: cvs tag コマンドは、特にファイルを明示しなかった場合「手元に実在している」ファイルだけを相手にします。厳密なタグ操作を行いたい時は cvs rtag コマンドを使いましょう。
CVSリポジトリの修正方針†
基礎知識†
- PukiWikiのCVSリポジトリは ソースの文字コード、コミットログの文字コードともに EUC/LF です。幸いなことにクロスプラットフォーム運用が可能な状態であるので、Unix系OSでも、Windowsでも(WinCVSごった煮版を使えば)問題なく作業ができるはずです。*9 -- henoheno
- PukiWikiはPHPの製品であるため、ファイルに実行権は不要です。新たにファイルを追加する際は、 (chmod a-x hoge.php && cvs add hoge.php && cvs ci -m "" hoge.php) といった要領で、ファイルに実行権限がつかない様にして下さい。つけてもリリースパッケージには影響は出ませんが、見た目よろしくありませんので、(以前やったように)SF.jpにクリンナップを依頼することになるかもしれません -- henoheno
依存関係の解決 / 作業の分割†
- 特定の修正に関するニーズがあって、それをする前にしなければいけないことがあった場合、そちらの修正を先に検討してください。 -- henoheno
- 既存の関数や機能の汎用化
- 既存の関数や機能ののクリンナップ
- 依存しているBugTrackの修正 etc
- いくつかの要素に分割できるようなパッチや、いつのまにかあれこれ修正が入ってしまったパッチ(あるいは作業途中のファイル)は、なるべく分割して、意味がひとつひとつ検証できるような形でコミットして下さい。ただし、拙速もまた良しです。でも後で泣きます。 -- henoheno
簡潔なdiffを作る†
- PEAR標準コーディング規約 (参考)
- http://pear.php.net/manual/ja/standards.php
- 従来のPukiWiki(大雑把に俯瞰した場合)と比較して、以下が異なります
- インデントはハードタブ(タブ記号)です
- PHPDoc はほどんど使われていません (使おうぜという声はたまに上がっています)
- ファイルヘッダは簡潔です。プラグインによってはその経緯からバリエーションが多少あります。
- CVSタグのネーミングルールはPukiWiki独自のものです。*10
- 関数名・変数名は基本的に小文字で揃っています。しかしオブジェクト指向の要素(クラス)が使われている部分ではほぼPEARのスタイルになっていると思います。
- プライベート関数や変数の直前にアンダースコアは...付けましょう。
- 最近用意しているpukiwiki標準関数には pkwk_ というプレフィックスを付けています。
- プラグインの定数は今まで非常に不揃いだったため、 PLUGIN_<プラグイン名>_<目的> といった形式に揃える様にしています(1.4.4から)
- コミットする前には、不要な要素や、足りない要素がないかチェックし、あれば削ったり補ったりして下さい。具体的にはcvs diff -u | less などで、これからコミットする内容をチェックして下さい。再修正を行った場合、再び cvs diff でチェックして下さい。そうしないと、後で検証する人(※特に自分)が泣きます。 -- henoheno
- 一つ一つのコミットは、必ず 動く 状態を維持しているものをコミットして下さい。つまりPukiWikiの場合ならPHPのコンパイルが必ず通り、PukiWikiが普通に立ち上がる状態を維持してください。そうでないと、CVS版を追っかけている冒険者や、並行開発をしている他のメンバーが困ります。 -- henoheno
- ひとつの変更が「複数のファイルの修正」を伴う場合、それを同時ないし短い時間で、かつ同じコミットログ(コミットログの項参照)でコミットして下さい。CVSはファイル単位にリビジョンを管理していますから、同じ瞬間に誰かがチェックアウトしていた場合、一部のファイルだけ古い状態になっている可能性がありますので、なるべく間は空けない様にして下さい。そうでないと、CVS版を追っかけている冒険者や、並行開発をしている他のメンバーが困ります。 -- henoheno
コミットログ†
- 直前のコミットの作業漏れをフォローする時や、全く同じテーマを連続コミットするようなときは、同じコミットログを使ってみてください。cvs2cl(ChangeLogを生成させているツール)はそのようなコミットを一つにまとめて見せてくれます。実例はChangeLogを見てください。 -- henoheno
- コミットログは原則として英語でやっています。コミットログの先頭には、可能であれば BugTrack のページ名を記しています。 -- henoheno
- wiki/ 以下のページをコミットする際は、なるべくencode前のページ名をコミットログの先頭に付加するようにしています。 -- henoheno
- 誰かの仕事の代行であるときは、コミットログにもその事実を書いて下さい。(Pointed out by hogehoge) とか (Patch by hogehoge) とか。 -- henoheno
- コミットログですが、ページ名を盛り込んでいるので最低限の追跡は可能なのですが、コミットログを(例えばChangeLog)一覧した際に後で自分が困らないように、簡潔かつ具体的なものにしておくと良いです。 Fix. Suppressing '--' divider with #comment(noname,nodate) とか。cvs admin -m "revision:New commit log" file で後からでも直せます。私は良くこれで直します(typoとか・・・)。 -- henoheno
- ちなみに、私はFixとかCleanupとかCorrectとか、最初の単語で「この変更はヒトコトで言えばナニだ」というのを言ったりしています。 -- henoheno
- osdev-j:CVS/HOWTOの最後にある「 CVSユーザーの良い習慣とは*12」の項にまとめてありますが、タグに対してブランチを切る様にすることと、後々混乱せず/他とぶつからないタグ名およびブランチ名を使用する事さえ守っておけばそんなに大したことではありません。 -- henoheno
- リリースタグ(r1_4_4とか)を作業の基準にする時はブランチポイントタグを打つ必要はありませんが、今回の場合CVS版で作業されているのでしょうから、まずpukiwiki_2005-03-19_autoalias といったタグを打ち、このタグから branch_pukiwiki_2005-03-19_autoalias といったブランチを切る様にすればOKです。 -- henoheno
- お手元の作業環境が一部CVS上の最新ではなく、それを維持したい場合、その作業環境でtagを切れば問題ありません。CVSはお手元のファイル(正確にはCVS/Entries)に記録されているリビジョンにタグを打ってくれます。 -- henoheno
- 具体的な動作確認については、cvs:../sandobx でいくつかブランチを切って見るとよろしいかと思います。 -- henoheno
- 作業が一段落した時は、(私ならそのブランチの末端にさらにタグを打ち) trunkをチェックアウトして、「cvs up -j ブランチポイントタグ -j 最終成果その1のタグ」のように実行してブランチの差分をtrunkに自動マージさせます(コンフリクトは別途解消のこと)。 -- henoheno
- 仮にそのブランチの作業が延長したときは、それが一段落した時点で改めてブランチの末端にタグを打ち、trunkに対して「cvs up -j 最終成果その1 -j 最終成果その2」のように実行してふたたび差分をtrunkに自動マージさせます。 -- henoheno
- ブランチポイントタグは明確に用意しておかないと、マージのときに明確な差分を作ることができなくなるため、はまります(余計な手作業が発生します)。特に多数のファイルを抱えるリポジトリの場合、死ねます。 -- henoheno
- ちなみに、この手のブランチ操作はPukiWikiだとPHP5対応の時に既に行われています。 -- henoheno
リビジョンのbackout (意図しない修正を加えたとき)†
- cvsを前のリビジョンに戻すときは -o ではなく、過去の差分を新リビジョンでcommitしませう。 @ BugTrack2/146 -- にぶんのに
- 了解です。実はどっちにするか悩んだのでした・・・。以後、気をつけます。 -- teanan
- そろそろこのページではなくて、「運用管理者のためのcvsガイド」のようなコンテンツにまとめるべき内容になっていますが (^^; 補足しますと、該当のリビジョンをチェックアウトしたクライアントでは、CVS/Entiries ファイルにその(もう存在しない)リビジョンと、チェックアウトしたファイルの最終更新時刻が記録されてしまっています。そのため、該当のファイルやディレクトリを一旦どかすなりしてやらないと、cvs up が意図通りに動作せず、そのファイルについてはcvsリポジトリとの同期が一瞬取れなくなります。(開発者の側で二回くらいコミットすれば直るかも) -- henoheno
コメント†
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
