忘れないうちにメモをしろ 2005-03〜


(2005年はMTで書いた日記のプログラミング関係をhtml化しなおしたもの)




 2005-03-11 玄箱HGにdebian (1)

半年ほど前から出先の会社で使用していることもあって、自宅にもCVS の代わりに Subversion(サーバー)がほしく思い、 ってのが当面の目的で(linuxにもちょっと触ってみたいし、で)、 玄箱HG のDebian化をしてみた。 (年末に衝動買いしたのにやりかけ放置だといつまでも悔しで^^;)

以下、そのメモ書き。

2005-04-10 tateisu
dpkgの質問が多いのは、 dpkg-reconfigure debconf で See only questions that are of what priority and higher? を変えると大幅に減ったはずですよぅ
2005-04-10 tenk*
うお、こんなとこにコメントする奇特な人が…と思えば君か^^; ありがとう。とりあえず、highにしてみた…が他に何するわけでもないので、さて(ああ休日がほしい...)



 2005-03-12 玄箱HGでdebian(2) (subversion)

  • 元より何度かインストールし直すのは予定の内だし、で、 気を取り直し、イチから再インストール。

    今度はこちらdebian化初期設定を ざっくりやったら、とっとと、こちら をみて sarge化。 今度は余計なものも(少)なく、無難にinstall。
    (こちら, やこちらも参考になるか)

    で、こちらの続きで他に入りそうなものをインストールして。

  • ああと、再ログインしてみたら、すぐさまログイン入力画面が。 woody化したとき やたらとログインまでに待ち時間があったのが嘘のように...なんか設定がわるかったのかon_ (毎度そんなだから、てっきり)

  • ついで こちらをみて Apache2を入れみる。 (Apache2はApacheと同時インストールできるみたいだけど、 2だけでいいよね、で)
    問題は設定関係で、Apache2 は Apache から定義ファイル/ディレクトリの 構成が変わっているようなので、さて... と思いきやちゃんと こちらに ありがたく。

  • で、やっとこさ本命、Subversion
    sarge にしたら、
    # apt-get install subversion
    でちゃんとインストールされている。コンパイルの必要はないのだった(っほ)。
    subversion不徹底入門 等をみて subversion-server subversion-tools もいる模様...が現状は -server という名前でなく libapache2-svnというのが必要のよう。

    # apt-get install subversion-tools
    # apt-get install libapache2-svn

    でインストール。

  • 先の頁こちら等の該当箇所をみて。
    とりあえず、リポジトリを /home/svnrep に作るとして。

    # svnadmin create --fs-type=fsfs /home/svnrep

    Berkeley DBは壊れっぽいかもということなので fsfs に (実際出先で何度か壊れ?復旧作業が発生しているのみると)。

    /etc/apache2/mods-available/dav_svn.conf の必要箇所の #を外して、 SvnPathを自分の都合に変えたものに修正して、

    <Location /svn >
      DAV svn
      SVNPath /home/svnrep
      AuthType Basic
      AuthName "Subversion Repository"
      AuthUserFile /etc/apache2/dav_svn.passwd
      <LimitExcept GET PROPFIND OPTIONS REPORT>
       Require valid-user
      <LimitExcept>
    <Location>
    
    ユーザー&パスワードを

    # htpasswd2 -c /etc/apache2/dav_svn.passwd USRNAME

    で追加。
    ※ 最初、考えなく他サイトのを書き写して
    #htpasswd2 -c /etc/subversion/passwd USRNAME
    とかして失敗。 dav_svn.conf中の説明にあるように AuthUserFile に設定してあるのと同じファイルを指定しないと^^;

    ※てことは プロジェクトごとにロケーション名 (<Location /NAME >)と リポジトリパス名(SvnPath) 変えたの用意してパスワードは共通って設定もありなんかな? 試してないけど... てかパスワード周りは別の方式も調べんと。


    その他subversion関係の頁。
    subversion.bluegate.org (各種和訳等).
    Subversionについてのメモ
    Saisse's Wiki
    vimrc diary
    Subversion/Windowsへのインストール



     2005-03-15 玄箱でvzなneのリコンパイル

    玄箱のdebian環境のgcc(2.94)で VZな ne (v3.05)をコンパイルすると 2箇所ほどエラーでひっかかったので、そのメモ。

    ・ menu.c の makev_proc() にて、
    args=*(va_list *)vp;
    *(va_list *)vp=args;
    の2行のキャストでコンパイル・エラー。 args の代入の必要はなさそうなので

    void makev_proc(int a, mitem_t *mip, void *vp)
    {
        char        *p = va_arg(*(va_list *)vp, char *);
        if (p==NULL) strcpy(mip->str,"null");
        else         strcpy(mip->str,p);
    }
    
    な感じで逃げる。

    ・ setopt.c 中の void config_read(char *path) にて、 char 定義な変数 c と EOF と比較してるが gcc(ppc)のデフォルトcharが符号無のためマッチできず 無限ループ。定義 char c, *p; を int c; char *p; に変更。

    その他警告もあるけれど、とりあえず動く模様。


    ついでメモ。gcc のインストールはとりあえず
    # apt-get install gcc
    # apt-get install libc6-dev
    ということらしい。
    fdclone のコンパイルには ncurses がいるようで、
    # apt-get install libncurses5-dev
    てことらしい。ライブラリ関係はlib〜-dev てことなんか?

    2005-04-10 tateisu
    libhoge-dev - hogeに依存した何かを作るのに必要 て分かれてるのが多いですね。libhoge-perl とかはperlモジュールの表記でまた紛らわしい。



     2005-03-19 Subversion はバイナリ格納で差分管理してくれてる...?

    Subversionを使いたい理由の一つとして、 cvs と違ってバイナリデータを バイナリ差分で格納するらしい、 ってのがあります。 (つーかテキストとかも バイナリで管理してる、みたいなことが 書かれてたようにも)

     もちろん、jpg とかzipとか圧縮され毎度ビットイメージが 違うデータの差分なんぞは期待しませんよ。

     例えば無圧縮 tga ファイルの修正差し替えのときなんかは どうかな、とかね...
    で、ちょっとお試し。

     顔の表情だけ違う、アドベンチャゲームの立ち絵データの 640x960 ARGB32ビット色のtgaファイルを2つ用意して、 仮に A,B として。

     A,B共にファイルとしては 2457644バイト(約2.35MB)。 fc.exe /b で差を取ると 352036 バイト違う模様。 (大体1/7、顔部分の面積からいってそんなとこという値)。

     で、これらを適当な名前で登録した時のsvnリポジトリの増分を 見てみることに。

    リポジトリ
       容量 (前回との差)  db/rvs (前回との差)
      98852                38535            [0] 登録前
     742677 (643825)      682268 (643733)   [1]A登録
    1287938 (545261)     1227437 (545169)   [2]Bで更新
    1289520 (  1582)     1228927 (  1490)   [3]Aで再度更新
    

     svnリポジトリは前々回、玄箱に設定したモノ subversion 1.1.3。データベースは fsfs 。(クライアントはWin機で tortoiseSVN 1.1.3)。
     上記のリポジトリ容量は、そのディレクトリで du -c -b . を した結果から。db/rvs はリポジトリ・ディレクトリの中でも特に変化の あったディレクトリ(実際にデータが蓄えられてる場所... 結果からすれば どちらか一方だけでよかった模様)。
     でA登録での増加分は、元サイズの1/4強... 圧縮かかってるやん。
    [3]時の A の再更新したときの増分をみれば、少なくとも同じデータが 過去にあると、同じであることを認識して? 管理情報だけ増えている ようにみえますね。

    問題は B 登録で、A登録よりも増分がすくないのは、圧縮方式のせいなのか 差分も取られているせいなのか...元画像の質からいって圧縮後のサイズ で100K違うことはないと思うけど...ちとよくわかんない。

     試しに元画像tgaをいくつかの方式で圧縮してみる。

            A           B
    tga     2457644     2457644
    png      507487      508997
    ???      652096      653836
    
    lzss     924046      924805
    lh5      493654      494660
    zip      456799      457542
    cab      363463      365483
    7z       322676      324688
    bz2      288165      291244
    

    嬉しがって無意味にいくつも試してしまった^^;
    圧縮時の元ファイル名がそのつど適当だったり zipやcab等オプション次第で圧縮率は変わるので 細かい値は無意味なんですが、大体どんな性質か、 くらいがみえてくればで。
    (ちなみに lzss は、 こちらにあったもの。 ほんとはビットストリームを用いない(軽い)圧縮ということで larc を探してたのだけど見つけられず...今回はこれで十分として。
    ??? は別頁にもちと書いた自前の画像圧縮ルーチンでの結果。 画像専用だけどビットストリーム無しの例として... 他人に意味なくとも己には事情がわかるからよし、と)。
    だいたいlz5とかzipとかと同系等の圧縮かな... って、単に zlib 使ってるだけなのでは... ソースをみれば...zlib を採用してますね... 最初に確認すればon_

    まあ、単純に別々に圧縮しただけなら(どの圧縮方式だとしても) A,B で100Kも違ことは無いだろうで、差分とってはいそう、かな、と。

    もういくつかテスト。

    リポジトリ
    db/rvs容量 (前回との差) 
    1738606 (509679)  [ 4]Aをpng変換したものを別途登録.
    2250332 (511726)  [ 5]Bをpngにしたもので、更新。
    2762060 (511728)  [ 6]Bの最後に00を1バイト追加したもの.
    2763268 (  1208)  [ 7]前回追加した最後の00をFFに書換
    3274994 (511726)  [ 8]前回の先頭 8バイトを
                          12 34 56 78 9a bc de f0 書換.
    3276212 (  1218)  [ 9]前回の0x40000番地から4バイトを
                          12 34 56 78 に書換.
    3277421 (  1209)  [10]前回の先頭1バイトを00に書換.
    3278628 (  1207)  [11]前回の0x40000番地からの8バイトを
                          fe dc ba 98 76 54 32 10 に書換.
    

    という感じ。
     面倒なんでdb/rvsの容量だけ(リポジトリ全体もそれに合わせてって感じで 他のディレクトリが大きくかわることもなかったので)。

     [5]の結果は圧縮データの再登録なので、さらなる圧縮もされず、差分も取られず、って のはそんなものでしょう。
    しかし [6] で1バイト増加しただけで全格納ぽいのは...で、[7]以降を適当に やってみたのですが... (先頭8バイト変えたときに全納になるのに真ん中へんだと差分だったり、先頭も1バイトだけ だと差分だったり....まあ、適当すぎるので、傾向なんぞわからなくて当然)

     とりあえず、ここまでの感じでは、
     バイナリ更新で可能なら差分&圧縮して管理してくれてる。
    けれど、期待しすぎるほどには賢くないかも。
    てとこでしょうか。
     いろいろ試さないと性質はよくわかんないけれど、 サイズが1バイトでも変わったら必ず全納かどうかは、現状の版ではそれっぽいかな、て気も。 (そー思って使うのが安全)
    どっかに解説がありそうな気もしますし、ソースみれば、ってのも。 将来の版では良くなっていきそうな要素だし。

    とりあえず、現状はそんなものか程度に納得。