SVN の pristine は svn cleanup で削除される ― 2017年07月27日 17時06分29秒
調べ直すと、svn cleanup で必要のなり pristine ファイルが削除されるのを見付けた。cleanup はロックが残ってしまった時だけだと思っていた。
/usr/obj は別にしてあり、/usr/local も別れている。インストールされているファイルは 1.5GB あり、残りの 3.5GB から 4GB が /usr/src にあるようだ。
cleanup で 1GB 程のファイルが消されたようだ。結構この処理には時間が掛かった。
% df /usr
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ada0s3d 7103150 5126298 1408600 78% /usr
% cd /usr/src
% svn cleanup
% df /usr
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ada0s3d 7103150 3936964 2597934 60% /usr
FreeBSD のコードを svn switch すると時間が掛かる ― 2016年08月22日 12時47分21秒
前回にやったときもそうだったが、svn switch に随分と時間が掛かる。こんなに時間が掛かるとは思っていなかった、覚えていなかったので、時間は計っていないが、三十分ぐらいは掛かっただろう。一度、電源を落すのを諦めて少し放置して待っていたぐらいだった。
systat で観察すると、コードの更新は早かったが、メタデータの更新に時間が掛かるようだ。svn switch は時間に余裕があるときに行う必要がある。
SVN pristine の実験 ― 2015年09月18日 12時17分42秒
そこで、/usr/src を最新にし、それと同じリビジョンを新しくチェックアウトしてみる。
見ての通り、一年以上あれこれと保持してきた .svn ディレクトリは、五割増しになっている。
% svn up /usr/src
...
Updated to revision 287945.
% du -sh /usr/src/.svn
1.5G /usr/src/.svn
% svn co https://svn0.us-east.freebsd.org/base/head /tmp/src
% du -sh /tmp/src/.svn
1.0G /tmp/src/.svn
次はどのくらい違うか調べてみる。
三割くらいファイルが多いようだ。
% diff -urp /usr/src/.svn /tmp/src/.svn | tee /tmp/diff.out
Only in /usr/src/.svn/pristine/00: 0001d6a6dcc4d283267971aa4fc0de0c2e7d7200.svn-base
Only in /usr/src/.svn/pristine/00: 0003fd1242ddbbb6b5814d64e9525da4bb35844d.svn-base
Only in /usr/src/.svn/pristine/00: 00041fbcc5f74d9069baa0cb4db0b815299be901.svn-base
Only in /usr/src/.svn/pristine/00: 0006a98938688bca351aa84c389fd9576888d438.svn-base
% find /usr/src/.svn -type f | wc
89305 89305 6787015
% grep -v 'Only in' /tmp/diff.out | wc; wc /tmp/diff.out
26285 105140 2234225
26369 105404 2237049 /tmp/diff.out
入れ換えられるか試してみる。無論バックアップを取ってから試すが、その部分は省略。
あれこれ、いじってある。rsync で新しくチェックアウトした .svn に変更してみる。タイムスタンプを使うと同じファイルもコピーしそうなので、-c で。
% svn stat /usr/src
M /usr/src/contrib/top/display.c
M /usr/src/etc/rc.subr
M /usr/src/sbin/mount/mount.c
M /usr/src/sys
M /usr/src/sys/i386/conf/GENERIC
M /usr/src/sys/kern/subr_taskqueue.c
M /usr/src/sys/vm/vm_glue.c
M /usr/src/usr.bin/mkuzip/mkuzip.c
M /usr/src/usr.bin/top/machine.c
一つのファイルが変更されたことになっている。これは、svn revert で処理をする。
% rsync -acl --delete /tmp/src/.svn/ /usr/src/.svn
% svn stat /usr/src
M /usr/src/contrib/gdb/gdb/sparc64fbsd-tdep.c
M /usr/src/contrib/top/display.c
M /usr/src/etc/rc.subr
M /usr/src/sbin/mount/mount.c
M /usr/src/sys/i386/conf/GENERIC
M /usr/src/sys/kern/subr_taskqueue.c
M /usr/src/sys/vm/vm_glue.c
M /usr/src/usr.bin/mkuzip/mkuzip.c
M /usr/src/usr.bin/top/machine.c
取り敢えずのところは、問題は無いようだ。当面影響を見ることにする。
Subversion で実行ビットを立てる ― 2014年05月09日 07時08分38秒
% svn propset svn:executable on <list of files>
しかし、時折おかしくなるみたいだ。
%svn propget svn:executable <list of files>
とやって「*」が表示されていないと正しく実行権限が設定されていない。
% svn propset svn:executable '*' <list of files>
そんな時は、明示的に「*」を指定する。
Subversion でレポジトリを変更 ― 2014年05月05日 12時59分21秒
SVN も中央管理型なので、レポジトリを移動した時、プロトコルを変更した時、ミラーの交換したい時に、手元のコピーの情報を更新する必要がある。
SVN には svn switch --relocate があり、それを行う。svn relocate もあるみたいだ。
% svn help switch
...
--relocate : relocate via URL-rewriting
...
% svn help relocate
relocate: Relocate the working copy to point to a different repository root URL.
usage: 1. relocate FROM-PREFIX TO-PREFIX [PATH...]
2. relocate TO-URL [PATH]
...
SVN は同じ動作が複数のコマンドから出来る事が多い気がする。
SVN サーバを構築して FreeBSD のソースをミラーした時等に使える。丁度、SVN サーバの URL が公開されているので、例には持ってこいだ。
% svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports
でチェックアウトしてあるので
% cd /usr/ports
% svn switch --relocate https://svn0.us-west.FreeBSD.org/ports/head \
http://svnweb.icmpv6.org/ports/head
%
で変更できる。
SVN で FreeBSD の安定版 ― 2014年05月02日 10時53分56秒
https://svn0.us-east.freebsd.org/base/release/10.0.0 といったリリースは、本当にリリースのみの、タグの位置付けの様だ。最近では openssl の SA などが出ていたが、それらの修正はこちらには反映されない。
CVS の時の様に、ブランチをチェックアウトして、セキュリティ修正が順次的追いされるのは、https://svn0.us-east.freebsd.org/base/releng/10.0 等の releng の方みたいだ。
svn switch で release から releng に移動できる。
% cd /usr/src
% svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn0.us-east.freebsd.org/base/release/10.0.0
Relative URL: ^/release/10.0.0
Repository Root: https://svn0.us-east.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 262281
Node Kind: directory
Schedule: normal
Last Changed Author: gjb
Last Changed Rev: 260789
Last Changed Date: 2014-01-16 13:43:50 -0500 (Thu, 16 Jan 2014)
% svn switch https://svn0.us-east.freebsd.org/base/releng/10.0
CVS FreeBSD から SVN FreeBSD へ移行 ― 2014年02月19日 12時18分57秒
CVS でカーネルを取得できるのは、8.4 RELEASEまで。しかし、いきなり移行目的で最新を取り出すのは茨の道にわざわざ突っ込む行動。ローカルパッチを取り出すには cvs diff と patch を使わなければいけないので、異なるバージョンで行うと作業し辛い rej ファイルと格闘しなくてはいけなくなる。
それを避けるのは、単純に cvs と svn で同じバージョンを取り出せばいい。FreeBSD ではわざわざ全ての履歴を CVS から SVN に移してくれている。また、他のリリースに移るのにも svn のマージコンフリクトを用いた方が、作業効率が数段も良い。
手元には、9.1 まで追った cvs があるので、それで一例。9.1-RELEASE は 8.4-RELEASE よりも小さい数字だが、リリースの日付けは前なので、cvs にある。
% mv src src-cvn
% ( cd src-svn; cvs diff ) > 9.1-diff
% svn checkout https://svn0.us-east.freebsd.org/base/release/9.1.0 src
...
A src/include/utmpx.h
A src/include/rpcsvc/ypclnt.h
A src/include/rpcsvc/key_prot.x
U src
Checked out revision 262199.
% cd src
% patch -p0 < ../9.1-diff
...
% svn switch https://svn0.us-east.freebsd.org/base/release/10.0.0
最後に、10-RELEASE に移る場合は svn switch を使う。
Subversion で FreeBSD を取得 ― 2014年02月16日 14時43分03秒
ハンドブックに Subversion の項目があり、svnweb で取得可能なバージョンが見られる。FreeBSD で特別な事をしているわけでは無いので、この先はごく普通の svn。
FreeBSD SVN ミラーサイト を見ると、アメリカ西海岸と東海岸。そして、EU しかない。
西海岸在住なので、us-west を選んで始める。
% svn checkout https://svn0.us-east.freebsd.org/base/release/10.0.0 src
svn: E170000: Unrecognized URL scheme for 'https://svn0.us-east.freebsd.org/base/release/10.0.0'
% svn checkout http://svn0.us-east.freebsd.org/base/release/10.0.0 src
svn: E170000: Unrecognized URL scheme for 'http://svn0.us-east.freebsd.org/base/release/10.0.0'
ところが、http と https 共にエラー。devel/subversion に戻って、オプションを確認。
[x] SERF WebDAV/Delta-V (HTTP/HTTPS) repo access module
SERF を有効にする必要がある。
https の方が成り済まし詐欺を防げるので推奨とある。
% svn checkout https://svn0.us-east.freebsd.org/base/release/10.0.0 src
svn: E170000: Unrecognized URL scheme for 'https://svn0.us-east.freebsd.org/base/release/10.0.0'
Error validating server certificate for 'https://svn0.us-east.freebsd.org:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: svn0.us-east.FreeBSD.org
- Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
- Issuer: clusteradm, FreeBSD.org, CA, US(clusteradm@FreeBSD.org)
- Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
(R)eject, accept (t)emporarily or accept (p)ermanently?
今度は、特に問題なく終了。
FreeBSD の CVS も 8.4 で終わりみたいだ ― 2014年02月10日 11時56分53秒
% cvs stat Makefile
===================================================================
File: Makefile Status: Up-to-date
Working revision: 1.404.2.2
Repository revision: 1.404.2.2 /home/ncvs/src/Makefile,v
Sticky Tag: RELENG_8_4 (branch: 1.404.2)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
RELENG_8_4 (branch: 1.404.2)
RELENG_9_1_0_RELEASE (revision: 1.392.2.3.2.2)
RELENG_9_1 (branch: 1.392.2.3.2)
RELENG_9_1_BP (revision: 1.392.2.3)
8.4 Release 以降は cvs は更新されていない。
Subversion は今でも好きではなく、cvs で更新できる間は cvs でと、移行していなかったがそろそろ年貢の納め時の様だ。
何より痛恨なのは、Subversion はタグが作れない事。そのように設計されたとは言うが、設計そのものが間違っている。リリースビルドをするとき等は、ブランチでコンパイルし、成功した暁にタグを作りたい。逆だと、手順が二倍に増える。そして、タグをリリースビルド後に作って、タグにコードを svn switch すると、全てのファイルのタイムスタンプが更新されデバッガが、好ましく思わない。
ディスク容量が cvs の二倍必要。今は気にはしないが、何年も前に少ない容量で遊んでいる時は、影響が大きかった。これ自体は、特にリモートの場合に、diff や stat でアクセスを回避できるので、利点はしっかりとある。
ただ cvs は RCS の延長なので、コミットの単位がファイル毎等の問題があったのも事実。FreeBSD では利用者の一人に過ぎないので、svn を使うこと自体には不満は無いが、少し下調べが必要だ。
Subversion で mergeinfo を壊された時は svn merge --record-only ― 2011年08月08日 11時11分53秒
mergeinfo の過去のマージの履歴を消えているみたいで、以前に行なったマージを再度行なおうとする。svn はもちろんのこと衝突を起こし、一つずつ手での修正を強要してくる。
最初の頃は、何故起きているのか解らず、万一に備えて全部目視点検していた。しかし、既に何回も起きて、各々の目視点検は単に時間の無駄と言う結論に達した。
そんなときに使いオプションが、svn merge --record-only。svn merge の様に実際にファイルを変更せずに、mergeinfo のみを更新する。既にマージが終わっている番号を調べて、--record-only で一気に無視。
Subversion はタグが打てないという設計上の欠陥と相まって、継続的なマージがとても難しい。
最近のコメント