FTPプロキシ経由のログイン [Tips]
delegateなんかでFTPプロキシを立てた場合の使い方。
$ ftp プロキシサーバホスト名 プロキシサーバポート番号
FTP> user ユーザID:パスワード@ホスト名:ポート番号
Subversionリポジトリ引越しでエラー [Tips]
認証関係を別のスキームで扱えるのもSubversionの便利なところ。
Subversionのリポジトリはディレクトリ毎コピーすれば別のサーバでもそのまま使えるようになる。
…はずなんだけど、Internal Server Error発生。
Webサーバのログを見ると
引越し先のSubversionが古い場合などに起きるようだ。
この場合、一度dumpして新環境でloadすれば移行することができる。
いちいちバージョン気にするくらいなら、dump→loadしてしまったほうが楽だね。
Subversionのリポジトリはディレクトリ毎コピーすれば別のサーバでもそのまま使えるようになる。
…はずなんだけど、Internal Server Error発生。
Webサーバのログを見ると
引越し先のSubversionが古い場合などに起きるようだ。
この場合、一度dumpして新環境でloadすれば移行することができる。
いちいちバージョン気にするくらいなら、dump→loadしてしまったほうが楽だね。
タグ:Subversion
CVSからSubversionへの移行 [Tips]
かなりありふれたトピックですが。
とあるCVSが動いてる機器が無くなるらしく、いい機会なので現在運用中のSubversionへ移行することに。
CVSリポジトリをSubversionへ移行させるにはcvs2svnを使ってリポジトリの変換を行ってやればよい。
変換対象のCVSサーバには大量のリポジトリがあるので、CVSリポジトリ1つにつきSVNリポジトリ1つにすることにした。
移行先はLinux+Apacheという環境。
リポジトリのディレクトリをそのままCVSサーバからSubversionサーバへコピー。
cvs2svnにパスを通して実行。
元のCVSのコメントはシフトJISで書かれていたのでこんな書式。
変換元のリポジトリの規模とマシンスペックによるけど結構かかる。
変換されたリポジトリをSVNParentPathの下に置いてやって、ファイルの所有者を他と同じものにしてやればこれで完了。
・・・と思ったらCVSROOTが入っちゃってた。
別に入ってても支障はないけど、激しく邪魔なのでやりなおし。
オプション指定とかで除外できそうな気もするけど、よくわからなかったのでCVSROOTディレクトリを削除してもう一度変換。
これでOKっぽい。
とあるCVSが動いてる機器が無くなるらしく、いい機会なので現在運用中のSubversionへ移行することに。
CVSリポジトリをSubversionへ移行させるにはcvs2svnを使ってリポジトリの変換を行ってやればよい。
変換対象のCVSサーバには大量のリポジトリがあるので、CVSリポジトリ1つにつきSVNリポジトリ1つにすることにした。
移行先はLinux+Apacheという環境。
リポジトリのディレクトリをそのままCVSサーバからSubversionサーバへコピー。
cvs2svnにパスを通して実行。
元のCVSのコメントはシフトJISで書かれていたのでこんな書式。
cvs2svn --encoding=Shift_JIS --fallback-encoding=Shift_JIS -v -s [SVNリポジトリのパス] [コピーしたCVSリポジトリのパス]
※[SVNリポジトリのパス]は新規に作成されるため、存在するディレクトリ名はNG
変換元のリポジトリの規模とマシンスペックによるけど結構かかる。
変換されたリポジトリをSVNParentPathの下に置いてやって、ファイルの所有者を他と同じものにしてやればこれで完了。
・・・と思ったらCVSROOTが入っちゃってた。
別に入ってても支障はないけど、激しく邪魔なのでやりなおし。
オプション指定とかで除外できそうな気もするけど、よくわからなかったのでCVSROOTディレクトリを削除してもう一度変換。
これでOKっぽい。
closeの結果も評価するのだ! [Tips]
結構前からMovableTypeを使っているのだが、最近ページ生成したときにページが途中で途切れる現象がしばしば発生している。
サーバ(レンタルサーバ)が腐ってるのかと思ってしばらくは放置していたのだが、今日は二桁回生成しなおしても改善しなかったので、調査してみたところQuotaに引っ掛かっていたっぽい。
これがUI上では正常終了してるように見えるのでタチが悪い。
(後で自分のブログを見たら真っ白だったとかザラ)
なんでコレが正常終了なのかわからなかったので調べてみた。
#人の書いたPerlスクリプトを読むことほど苦痛なことはない
原因はcloseの結果をチェックしていないからだった。
今の会社に入って初めて担当したシステムでこれが原因の障害に巻き込まれたのだが、これがまたその後の対応を含めてこんな糞(うん)コード書いた奴の人生もcloseさせたくなるくらい入社早々辞めたくなるくらいのトラウマな出来事だった。
CとかPerlとかの入門書や入門サイト見てもopenの結果は評価してもcloseの評価をしている記述は私は見たことがない。
何バイト書いたとかチェックしても実際にはライトバッファに乗っかってるだけだから、本当に成功したかどうかはflushかcloseしないとわからない。
そういう意味ではJavaみたいに強制的にcatch書かされる言語は少なくとも意識させられるからマシだよね。
サーバ(レンタルサーバ)が腐ってるのかと思ってしばらくは放置していたのだが、今日は二桁回生成しなおしても改善しなかったので、調査してみたところQuotaに引っ掛かっていたっぽい。
これがUI上では正常終了してるように見えるのでタチが悪い。
(後で自分のブログを見たら真っ白だったとかザラ)
なんでコレが正常終了なのかわからなかったので調べてみた。
#人の書いたPerlスクリプトを読むことほど苦痛なことはない
原因はcloseの結果をチェックしていないからだった。
今の会社に入って初めて担当したシステムでこれが原因の障害に巻き込まれたのだが、これがまたその後の対応を含めて
CとかPerlとかの入門書や入門サイト見てもopenの結果は評価してもcloseの評価をしている記述は私は見たことがない。
何バイト書いたとかチェックしても実際にはライトバッファに乗っかってるだけだから、本当に成功したかどうかはflushかcloseしないとわからない。
そういう意味ではJavaみたいに強制的にcatch書かされる言語は少なくとも意識させられるからマシだよね。
Linuxばっかり使ってると忘れること [Tips]
多くのLinuxの/bin/shはBASH。
Linuxで動いたシェルスクリプトが別のUN*Xで動かない、と騒ぐ前に要確認。
cshもtcshだけど、Linux的にはほぼスルーでいいかな。
Linuxで動いたシェルスクリプトが別のUN*Xで動かない、と騒ぐ前に要確認。
$ ls -l /bin/*sh
-rwxr-xr-x 1 root root 716972 1月 6 2007 /bin/bash
lrwxrwxrwx 1 root root 4 9月 4 19:36 /bin/csh -> tcsh
-rwxr-xr-x 1 root root 1169832 3月 15 2007 /bin/ksh
lrwxrwxrwx 1 root root 4 9月 4 19:33 /bin/sh -> bash
-rwxr-xr-x 1 root root 343756 3月 15 2007 /bin/tcsh
cshもtcshだけど、Linux的にはほぼスルーでいいかな。