- 追加された行はこの色です。
- 削除された行はこの色です。
// * Subversion
#contents
* リポジトリを作る
svnadmin create /path/to/svn/repos
svnadmin create --fs-type fsfs /path/to/svn/repos
FSFSはBerkeley-DBが使えない場合(NFS上で運用とか)
* プロジェクトをリポジトリに追加
- /tmp/projectA がプロジェクトのファイルがあるディレクトリとする
- /tmp/projectAの中身は下記のようにしておくとよい
-- branches/
-- tags/
-- trunk/
--- プロジェクトのファイル
svn import /tmp/projectA file:///path/to/svn/repos/projectA -m 'initial import.'
- /tmp/projectA
-- 絶対パスである必要なし
-- 省略すると .
- file:///path/to/svn/repos/projectA
-- file:///path/to/svn/repos を指定するとリポジトリのトップにそのプロジェクトが置かれる
-- file:///path/to/svn/repos/Foo/Bar と適当に指定することもできる
- -m 'initial import.'
-- commitのメッセージ
* チェックアウト
svn co file:///path/to/svn/repos/projectA/trunk projectA
- file:///path/to/svn/repos/projectA/trunk
-- 自分の取得したい範囲を指定
- projectA
-- 展開するときのディレクトリ名
-- 指定しないとこと場合 trunk
svn co svn+ssh://user@host/path/to/svn/repos/projectA/trunk projectA
* ブランチ / タグ付け
- Subversionでは同じ扱い
- コミット対象がブランチ
- コミットしないで分岐時のリビジョンに名前を付ける目的のものがタグ
svn copy file:///path/to/svn/repos/projectA/trunk file:///path/to/svn/repos/projectA/branches/hoge-branche
svn copy file:///path/to/svn/repos/projectA/trunk file:///path/to/svn/repos/projectA/tags/release-1.0
* svnserveの起動
# 適当な権限のユーザになって
svnserve -d -r /path/to/svn/repos
参考
- svn+sshはsvnserveを起動なくてもいい
- svn+sshはsvnserveとは関係ないのでフルパスで指定しないといけない
* svnserveで管理
- svn://www.oucc.org なアクセスになってしまう
-- ユーザレベルで動かしてこれはないよなぁ・・・
- svn://SERVER.NAME なアクセスになってしまう
-- ユーザレベルで動かしてるのにルートっぽいアクセスはないよなぁ・・・
- 設定は /path/to/repos/conf/svnserve.conf が読まれる
* 複数人で管理(svn+ssh / file)
** Berkeley-DB + 全開な方法
リポジトリのdb 777, db/* 666で動いてそうな気がする。
** FSFS + Group手抜きバージョン@井上研
# sは初めからついてる
chmod g+sw db/
chmod g+sw db/*/
chmod g+w db/write-lock db/current
* リポジトリレイアウト
http://subversion.bluegate.org/doc/book.html#svn-ch-5-sect-6.1 とか参照
- 1つのリポジトリに複数プロジェクトを入れる
-- 管理(フック、定期バックアップ、プロジェクト間のデータ移動など)が楽
-- どれかのプロジェクトが更新されるとリビジョンが増える(リポジトリに対してグローバル)のが気持ち悪い
- 1つのリポジトリに1プロジェクト
-- 管理が面倒
-- コミットメーリングリスト/権限設定を分けたりが楽
一人で扱う分には割とどうでもいい気がする
* dump/load
標準入出力にて
* トラブルリカバー
** Berkeley DBが壊れたとき
svnadmin recover /path/to/svn/repos
- 他の人が作ったログファイルなどがあるとrecoverに失敗する(半端に成功する)
-- chownしてもらう(パーミッションを変えてもらうだけでいいのかも
- db内のファイルがパーミッション644に戻っているので''666にする''(そういう管理の時は
** ファイルの追加失敗
commit成功したあとにupdateに失敗した場合
- 追加したファイルをいったん rm
- svn update
- commit log が残されたままになるので rm
commitメッセージ書いてる横でupdateとかしたら起こりました
* TortoiseSVN
- SSHクライアントが未指定だとわかりにくいエラーメッセージが出て困る
-- enとjpでは出てくるメッセージが違う(そしてどちらも本質を突いていない
* 属性削除
# 実行属性
svn propdel svn:executable FILELIST
# バイナリ
svn propdel svn:mime-type FILESIT
なんかインポートしたらバイナリだと判断されたものがあったりしたので