タグを頻繁に切るようなプロジェクトでのsvkの使い方。これでいいのか?

ここ最近はsvkを使ってバージョン管理をしているんですが、svk help introで見ることができるイントロで紹介されているように 、

>

# リポジトリをミラー
svk mirror svn://svn.example.com/project_x //mirror/project_x

# リポジトリを同期
svk sync //mirror/project_x

# ローカルリポジトリを作成
svk copy //mirror/project_x //project_x

<

として、同期したproject_xのリポジトリをそのままローカルリポジトリにするという方法でしばらく使っていました。最初はこれで問題ないように思えたんですが、元のリポジトリでブランチやタグを切った後、svk pull //project_xして、リポジトリの同期をとると、ブランチやタグがファイルの実体としてコピーされているようだということに気づきました。

僕の会社でのsubversionの使いかたは、trunkで開発を進めて、リリースの準備ができたら、ブランチを切り(例えば branches/RB-2.3)、実際にリリースする時にはタグを切る(例えば tags/REL-2.3.0)という形をとっているので、結構タグを切ることが多いです。

これだとタグを切るたびにsvk pullするとそのプロジェクト分のファイル容量が消費されてしまい、すごくディスクを無駄にしているような気がしていました。

そこで考えたのが以下の方法。

>

# リポジトリをミラー。ここは同じ
svk mirror svn://svn.example.com/project_x //mirror/project_x

# リポジトリを同期。ここも同じ
svk sync //mirror/project_x

# trunk,brancheのローカルリポジトリをそれぞれ作成。ここを変更
svk copy //mirror/project_x/trunk //project_x-trunk
svk copy //mirror/project_x/branches/RB-2.3 //project_x-rb2.3

<

ローカルリポジトリを作成する際にリポジトリそのままではなく、トランクとブランチをそれぞれローカルレポジトリとして作成してみました。
今はこの方法で開発をはじめてますが、pull, push,なんかも問題なくできますし、トランクの作業コピー上で、svk smerge //project_x-rb2.3として、リリースブランチの修正をトランクにマージすることもできているので、問題はなさそうです。

もうひとつ、考えられる方法として、mirrorする際に、trunkをミラーするという方法もできそうですが、なんかこの方法だと管理が複雑になりそうだったので上記の方法をとりました。

svkは結構柔軟にいろいろできるっぽいので、他のひとがどういう風に使っているのかちょっとしりたいなーと思いました。