カテゴリ | |
---|---|
サマリ | PukiWikiのバージョンアップ |
バージョン | 1.4.1 |
投稿者 | JAVA |
状態 | 完了 |
投稿日 | 2003-11-10 (MON) 15:40:48 |
現在使っているのが1.4で、1.4.1が出たのでアップしようと思います。
そこで、質問というか要望なのですが、このようなマイナーアップの場合は、変更のあったファイルをまとめたアーカイブも作ってもらえないでしょうか?
要は、差分ファイル群をまとめたものですね。
「コレらを上書きしてくれればバージョンアップできます」、というようなものです。
CVSでバージョンアップ(updateコマンドとか)できそうですが、一般のサーバだと、ファイルをアップすることしかできないので・・・
こうしていただけると、バージョンアップが簡単にできてよいのですが、いかがでしょう?
それとも、そもそもwikiディレクトリ以外を上書きすればいいだけのものなのでしょうか・・・すみません、プログラムを読んでいないのでわからないのですが・・・
*.phpファイルなどについては「自作プラグイン/cvscheck.inc.php」で容易に確認できるので、むしろファイル内にバージョン情報が記載されていない、readme.txtやら./wiki/以下のファイル群などで更新されたファイルがまとめられていると嬉しかったりします。というわけで、それを希望。
それだって、CVSで確認すればよいのでは?Webで簡単に差分だって、色を変えて綺麗に確認できるじゃないですか?
もちろん全てのファイルを逐一確認すれば可能ではありますが、それは大変な負荷です。PukiWikiの梱包ファイルは./Wiki以下でも26個もありますし、全体では既に200個に届きそうなほどあるのですから。
アップデートに際しては、ファイルのどの部分が変更されたかが欲しい訳ではなくて、変更されたファイル自体を容易に入手したい訳です。cvscheck.inc.phpを作ったのも、それが動機なのですが、内部にバージョンが記載されていないファイルには未対応なのです。
./wiki/と./と./plugin/だと駄目なのがよく分からないだけです。どのくらい前に更新されたか一目瞭然じゃないですか。たいした作業でも無いですよね?
どのファイルが更新されたのかをユーザが拾い出さなければならない点にCVSの不便さがあります。それはたいした作業どころか、とても面倒な作業です。これがアップデートの大きな障害だと感じています。だから私はcvscheck.inc.phpを作りました。ここの感じ方は人それぞれだと思いますが、私のようにその確認作業に大きな抵抗を感じてしまう人も多いかと思いますので、出来ればその辺を便利にして頂きたいと要望したい気持ちを持っております。
例えば、一つの提案ですが、./wiki/以下やreadme.txtなどのドキュメントファイルにもプラグインと同じ形式のバージョン情報を埋め込むというのはいかがでしょうか。そうしますと、cvscheck.inc.phpの対象ファイルとなりますので*1、更新ファイルの確認作業をcvscheck.inc.phpに任せることができます。ユーザは表示されるファイルを更新する作業をすればよいだけとなります。
お返事ありがとうございます。
cvscheck.inc.phpは早速使わせていただきました。
一般ユーザとしては、やはり変更のあるファイル群を入手してアップ(上書き)すればいいだけという形が楽だと思いますし、
一般ユーザでなくてもそうしてくれたほうが楽じゃないかなと思って発言してみたのですが・・・どうやらcvsで差分を取る方が万人とっても楽だとおっしゃる方もいらっしゃるようで・・・
あとは製作者の方の暇次第、ということですかね。
ありがとうございました。
カスタマイズして使う人が多いので、「変更のあるファイル群を入手してアップ(上書き)すればいいだけという形が楽」だとは必ずしも言えないんですよね。丸ごと取ってきて、手元でカスタマイズしたものとの差分をとって、アップデートするという方法の人も少なくないですし。
私も、reimyさんの言われている通りです。そのまま反映はしていません。あと、ちなみに、私は、cvsで差分をとることはしていません。開発日記を見なくても更新が入ったかどうかが分かるので、これで利用している程度です。更新が入った場合には、最新版のtar玉を取得し、必要なら、自分が利用しているtar玉とのdiffをとり、diffstatコマンドで更新ファイル一覧を作る。という作業を行うだけです。これもバッチでtar玉取得(wget)から、全部自動でできちゃいますからねぇ。また、これらコマンドも、Windows下でも動きますしね。
おっしゃる通り、確かに私も一部カスタマイズしてますのでcvscheckが便利なのですが、とにかくお手軽に使いたいという人のニーズも捉えておかないと、なかなか普及に弾みがつかないような気もします。現状でカスタマイズして使う人が多いという状況自体がそれを物語っているような気もしますよ。つまり、今回の例ですと「単に上書きすればアップデートできる用意がないから、それで済ましたいというユーザも集まってこない」*2のではないのかな?と思ったりして。。。そういう普及の観点で見ると、dev:BugTrack/481の$script自動設定も重要なものの一つだと思っています。
いっそのこと、aptとかup2dateみたいな仕組み、作りますか?ViewCVSありきでいけば、まぁ、やってできないとは思いませんしね。> shaさん
upkさんがそう言うとできるような気もしてきますね。でも、やり始めると、アップデートして動かなかったら戻せた方がいいとかいろいろ出てきそう。確かに、これが出来たらかなり親切なシステムに出来そうですが。。。と言いつつ、実は私は最近RedHatとかでアップデートしたことないので、aptとかup2dateの動作がよく分かってないのです。
何だか思いのほか口論(?)になってしまいましたが・・・
結局、ユーザが何を求めてWIKIを使うのかということだと思います。
そもそもWIKIはデザインをカスタマイズして使うものだとするか、そのままでいいからお手軽に使うか、の違いではないでしょうか?
デザインの変更にはPHPのソースをいじらなければできませんから、サイトは手軽につくれても、デザインは手軽には変えられませんよね。
私だってまじめにサイトを作るときはHTMLもタグから打ってCSSの調整もしてPHP他のプログラムも書くことはしますし、CVSだってバリバリ使っていますが、私がWikiを使おうと思ったのは「手軽にメモ書きやドキュメントを書きたい」からであり、したがって設置やアップデートやカスタマイズをしてよりカッコイイ(?)ページが作りたいからじゃないんですよね。
私は「お手軽」がウリだと思っているので、アップデートまで「お手軽」にやりたいです。
ソースコードの変更までやったら「お手軽」なんて思えません。*3
何だか長くなってしまいましたが、「普通はソースを変更して自分オリジナルに仕立てるものだろう?」というのがWikiの姿勢ではないのでは、と私は勝手に思ったので、この質問だか要望だかが生まれたわけです。
口論というより有益な議論が出来てよい機会だったと思いますよ。なかなかこういう場で書きこみをして下さる方はカスタマイズも厭わない方々が多いかと思いますので、「お手軽だったら使ってもいいかも」のように、もっと大多数の寡黙なユーザのニーズを出していただけるのは非常に貴重だと思います。
そう思っていただければ幸いです。Wikiに限らず、プログラマのような人のレベルで「そのくらいは難しくないよ」「大した手間じゃないよ」と言ってしまうと、掲示板を設置したことがあるくらいの人ではついていけないでしょう。多分CVSなんて知らないでしょうし。折角、このような「お手軽」にサイトを作るアプリケーションを作ったのなら、とことんできる限りはやっていただきたいなぁという・・・まあ私の勝手な要望です(^^;
スキルのある人だって、やらなくていいことは、やりたくないって思う人は少なくないと思います。ここを無視すると、製作者が勝手に独りよがりで作って勝手に満足するアプリケーションになってしまいかねません。折角このようなコミュニティーができたのですから、活発に意見をやりとりし、柔軟に受け入れていって欲しいなあと思います。
1.4.2のリリースから、変更ファイルだけのアーカイブや差分も同時に公開するようになりました。
あら、本当ですね。ありがたいです。