|
[374] Re2:ヘルプソースの管理・運用変更案 | |
|
▽ 2007/10/7 (日) 18:39:16 ▽ maru |
| ▼ じゅうじさん
念のための確認ですが、中間ファイルと表現しているのは、ヘルプましんから見れば中間ファイルですが、本来の姿（HTML Workshop）ではプロジェクトファイル本体や目次ファイルなど（hhp,hhc,hhk）のことを指しているつもりです。
そして、hhp,hhc,hhkの追加の件は「HTML Workshopだけのユーザーでもコンパイルできるように」の意味よりは、「ヘルプましんは管理しにくいから離脱したい」の意味が強く、どちらかというとヘルプ作成者側の都合です。
作業感覚的には、これまでHTMLWorkshopのフロントエンドがヘルプましんだったものを、今度からテキストエディタ(普通はサクラエディタ)に変更しよう、という話です。
ここまでは、お互いの認識は合っていますよね？
さて本題ですが、以前の書き込みではWorkshop側のメリット・デメリットだけを列挙したので、主張が分かりにくかったかもしれません。
■ヘルプましんで管理するデメリット
１．コンパイルにはHTMLWorkshopとヘルプましんの２つのソフトが必要。
２．HTMLWorkshopに比べて、インストールされた環境が限定される。
３．コンテンツツリーがバイナリで保存されているので、変更点がわかりにくい。
４．コンテンツツリーがバイナリで保存されているので、パッチ配布できない。
５．コンテンツツリーがバイナリで保存されているので、別々の修正をマージできない。
６．コンパイル前には、hhp内のパス指定を修正しなければならない
７．６の理由により、リリースファイルのコンパイルは２段階の作業になってしまう。
８．ソース配布前には、XHP内のパス指定を修正しなければならない
９．７と８の理由により、７の作業でコンパイルの動作確認済みのソースはそのまま配布できず、コンパイル実施前の状態を別途保持しておかなければならない。
10．９の理由からリリース直前の細かい修正にはバージョン管理が煩雑になるが、６や８の作業が抜けても気が付きにくい。
■ヘルプましんで管理するメリット
１．UIが日本語
２．ヘルプましんからコンテンツツリー構造を変更・保存してもmerge指定が壊れない
といった状況です。
ヘルプましんの方がリリースにいたるまでのローカルルールが多くて、SVNでの管理にも不向き、というのが主な提案理由です。
> hhp,hhc,hhkを追加するのは賛成です、削除するのは反対です。
ヘルプましんとWorkshopの両サポートという意味でしょうか。これは間違いなく前以上に面倒だと思うのですが。
いずれの結論の場合も、最終的にはどちらか一方にさせてください(^^;;
|
|
|