(2005年はMTで書いた日記のプログラミング関係をhtml化しなおしたもの)
半年ほど前から出先の会社で使用していることもあって、自宅にもCVS の代わりに Subversion(サーバー)がほしく思い、 ってのが当面の目的で(linuxにもちょっと触ってみたいし、で)、 玄箱HG のDebian化をしてみた。 （年末に衝動買いしたのにやりかけ放置だといつまでも悔しで^^;)
以下、そのメモ書き。
当然 玄箱うぉううぉう♪や こちら, こちら, こちら, こちら, こちら, こちら, 等その他サイトもたんまり参考させていただいて。 (ありがとうございます)
debian関係もいろいろ。Apacheの設定は Debianサーバ構築ガイドとか。
vz な ne は流石に apt-get じゃなく、 こちらより v3.05 の ソースを落としてコンパイル（だと、ちょっと駄目で要ソース修正）。
- 2005-04-10 tateisu
- dpkgの質問が多いのは、 dpkg-reconfigure debconf で See only questions that are of what priority and higher? を変えると大幅に減ったはずですよぅ
- 2005-04-10 tenk*
- うお、こんなとこにコメントする奇特な人が…と思えば君か^^; ありがとう。とりあえず、highにしてみた…が他に何するわけでもないので、さて（ああ休日がほしい...)
今度はこちらの
debian化
と
初期設定を
ざっくりやったら、とっとと、こちら
をみて
sarge化。
今度は余計なものも(少)なく、無難にinstall。
(こちら,
やこちらも参考になるか)
で、こちらの続きで他に入りそうなものをインストールして。
# apt-get install subversion-tools
# apt-get install libapache2-svn
でインストール。
# 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へのインストール
玄箱の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モジュールの表記でまた紛らわしい。
Subversionを使いたい理由の一つとして、 cvs と違ってバイナリデータを バイナリ差分で格納するらしい、 ってのがあります。 （つーかテキストとかも バイナリで管理してる、みたいなことが 書かれてたようにも）
もちろん、jpg とかzipとか圧縮され毎度ビットイメージが 違うデータの差分なんぞは期待しませんよ。
例えば無圧縮 tga ファイルの修正差し替えのときなんかは
どうかな、とかね...
で、ちょっとお試し。
顔の表情だけ違う、アドベンチャゲームの立ち絵データの 640x960 ARGB32ビット色のtgaファイルを２つ用意して、 仮に 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バイトだけ
だと差分だったり....まあ、適当すぎるので、傾向なんぞわからなくて当然）
とりあえず、ここまでの感じでは、
バイナリ更新で可能なら差分&圧縮して管理してくれてる。
けれど、期待しすぎるほどには賢くないかも。
てとこでしょうか。
いろいろ試さないと性質はよくわかんないけれど、
サイズが１バイトでも変わったら必ず全納かどうかは、現状の版ではそれっぽいかな、て気も。
(そー思って使うのが安全）
どっかに解説がありそうな気もしますし、ソースみれば、ってのも。
将来の版では良くなっていきそうな要素だし。
とりあえず、現状はそんなものか程度に納得。