北海道苫小牧市出身の初老PGが書くブログ

永遠のプログラマを夢見る、苫小牧市出身のおじさんのちらしの裏

SVKのpullは危険

どうもSVKに慣れません。昨日も暴走させました。しかも2回も。

経験的に、「チェックアウトしたワークコピーにpullを使う」ことによる失敗が多い気がします。以下、たまたま昨日暴走させた2例をメモしておきます。

そもそも、なんでワークコピーにpullするの?

updateの代わりについつい使ってしまうのです。mirrorして//localにsmergeもしてからワークコピーにupdateしてくれるって印象が強いので。

その一. mirror内のbranchをチェックあうとしたものへのpullは危険

ブランチを持つSVNを手元のSVKへmirrorして、そいつを//local等にコピーせずにそのままチェックアウトした場合です。このワークコピーにpullを使ったら、暴走して意図しないものがbranchへcommitされました。

予想

pull=smergeなので、trunkでの修正のうち未commitのものをbranchにsmergeするのではないでしょうか。その際、mirrorに直接反映されるので、SVNリポジトリにcommitされると。

その二. //local 等にcopyしたものの、下位ディレクトリのみをチェックアウトしたものへのpullは危険

通常*1SVKではmirrorしたDepotは直接使わず、こいつを//local/ 以下等へ copyしたブランチを開発に使います。この//local 以下のDepot の下位ディレクトリのみをチェックアウトして pull すると、この時点ではまだ大丈夫なんですが、その後 //local の Depot 全体に pull(smerge) をかけたときに意図しないcommitが発生したり、push(逆向きのsmerge)しようとすると競合が起きたりします。

予想

pullはsmergeなので、ワークコピー内で実行すると //local の下位ディレクトリにだけsmerge が実行されます。その後 Depot の上位ディレクトリにpullをかけると、既に最新となっている一部の下位ディレクトリと整合性がとれずにおかしな動きをするんじゃないでしょうか。*2

まとめ

pullは便利なupdateコマンドの代わりについつい使いたくなりますが、pull は単なるupdate ではなく s"merge" なので、mergeのうざったさを十分知って懲りている人であれば、使うべきではないということなんでしょう。

*1:codereposでは推奨されてないが、公式の使い方では、と言う意味

*2:SVKがブランチ単位ではなく、その中のディレクトリやファイル単位でマージの管理をしてるなら別ですが、きっと違いますよね?