"Subversion" は "SubVersion?" に非ず。
日本語などマルチバイト文字が含まれるファイルをコミットしようとすると、 次のようなエラーが出てコミットできないことがある。
Safe data (ファイルorディレクトリ) was followed by non-ASCII byte %d. Non-ASCII character detected (see above), and unable to convert to/from UTF-8
SVNサーバのLANG設定は正しい、かつ、今までは普通にコミットできていたのに、 急にコミットできなくなった、という場合は、次のチェックをしてみる。
これは確定的な原因がわからないので調査中。
Subeclipseで衝突(更新が競合)したファイルがあると、競合ファイルの該当箇所に相違点が書き込まれ、これとは別に次の3つのファイルが作成される。
該当ファイルがJavaなどのソースファイルであれば、Subeclipseが書き込んだコメントのためにコンパイルエラー状態になる。大きな相違がなければ、そのエラー部分を消して、新たにできた3ファイルも削除してやれば、普通にローカルで更新された状態になる。それをコミットすればOK。
updateしようとすると、次のようなエラーが出て更新できないことがあった。
Attempted to lock an already-locked dir svn: Working copy 'c:/workspace/webapp' locked
svnの処理を強制中断したりすると、ときどきこういう状態になるらしい。
この場合、問題のディレクトリをクリーンアップすればなおる。
cleanup c:/workspace/webapp
これでダメなら、一度該当ディレクトリを物理的に削除して(勿論、ソースファイルなどはバックアップして)、再度そのディレクトリをリポジトリから取得(チェックアウト)する。
主に Linux の Eclipse(Subeclipse) を使ってるときに起こりやすい問題で、 チェックアウトした作業コピーが、Subeclipse が使っている svn より新しいものでコミットされていると、 そのファイルを Subeclipse (というか、その環境)からコミットしようとしたとき、 以下のようなエラーが出てコミットできない。
svn: This client is too old to work with working copy '(filename)'; please get a newer Subversion client
svn: このクライアントは、作業コピー '(filename)' を扱うには古すぎます。 もっと新しい Subversion クライアントをダウンロードしてください。
これは、Linux でデフォルト(yum)でインストールされるバージョンが古いため。 例えば CentOS 5.5 で Subversion をインストールすると、1.4.x が入るが、 これだと、それより新しい svn でコミットされたものが扱えない。
yum を使うとどうしても古いのが入ってしまうので、この場合、ソースからインストールしてしまう。
以下その手順。
$ su # yum remove subversion
# cd /usr/local/src
# wget http://subversion.tigris.org/downloads/subversion-1.6.12.tar.gz # wget http://subversion.tigris.org/downloads/subversion-deps-1.6.12.tar.gz(2010/8/20 現在 最新は 1.6.12)
# tar xzvf subversion-1.6.12.tar.gz # tar xzvf subversion-deps-1.6.12.tar.gz
# cd subversion-1.6.12 # ./configure # make # make install
# svn --versionバージョン情報が表示されれば OK。