web-dev-qa-db-ja.com

SVNは、ファイルが別の作業コピーで私によってロックされていると頻繁に言います

バイナリファイルにneeds-lockが設定されたSVNリポジトリ（Dreamhostでホストされている）があります。私がロックして変更したファイルをコミットしているときに、次のエラーでコミットが失敗することがあります。

Error: Commit failed (details follow):
Error: File '/my/file.bin' is locked in
Error:  another working copy

そのファイルを（盗むことなく）ロックしようとすると、次のようになります。

Error: Path '/my/file.bin' is already locked by user
Error:  'my_username' in filesystem '/home/user1/svn/repo1/db'

クリーンアップは役に立たないので、これを解決する唯一の方法はロックを盗むことであり、それからコミットは成功します。

これは重大な問題ではありませんが、特に長いコミットの途中で発生する場合は、非常に厄介です。私は他の作業コピーを使用していないと確信しているので、これはクライアントまたはサーバーのバグが原因であると考える傾向があり、問題はかなり頻繁に（過去2日間に3回）発生しますと私の同僚はリポジトリを使用しています。

TortoiseSVN 1.8.4を使用していますが、Dreamhostsvnサーバーは1.6.12です。

助けてくれてありがとう。

更新：コミットする前に作業コピーを更新するとエラーが発生することに気付きました（エラーは発生せず、もちろんロックされたファイルは変更されません）。ファイルのステータスをチェックすることにより、更新亀が私によってロックされていると言う前に（ローカルでのみチェック）、更新後にローカルでチェックすると「????」が表示されます。ロック状態として、そしてサーバーをチェックすることによって、それはそれが私によってロックされていると言います。更新後、ファイルがまだ変更済みとしてマークされている場合でも、ファイルは読み取り専用になります（needs-lockのため）。したがって、アクションのシーケンスは次のとおりです。ロックfile.bin->ファイル.binの変更->作業コピー全体の更新->コミット->コミット失敗エラー。更新後、作業コピーはロックの状態を忘れているようで、サーバーに問い合わせると、別の作業コピーでロックされていると見なされます。

svntortoisesvndreamhost
13
cmant

Windowsでは、次の手順で問題を修正しました。1。メニューの[リポジトリブラウザ]をクリックしてリポジトリブラウザを起動します。 2.ロックされたファイルを見つけます。 3.ロックされたファイルをマウスで右クリックします。 4.「ロック解除」をクリックします。

37
Toby Han

クリーンアップは役に立ちません。これはコピーロックの作業に使用されますが、ユーザー間にミューテックスを実装する手段として、ファイルがリポジトリ自体にロックされるという問題が発生しています。 「ロック」の3つの意味 を参照してください。

おそらく、知らないうちに別の作業コピー（ローカルまたはサーバー上のWC）でファイルをロックしているクライアントがあるか、マウントしたWebDAV共有を持っている可能性があります。そこでファイルを開くと、ロックが作成されます。

3
alroc

また、同じ問題が発生し、3台のマシンのうち、1台のマシンでファイルをロックしたため、この問題に直面していることがわかりました。私がしたことは、そのマシンからロックを解除して、さらに先に進むことです。

OR

ロックを盗む最初に作業を開始します。これはSVNが提供する最良のオプションです。

2
LivCool

JetBrains IDEを使用している場合：

ロックを解除するファイルを右クリックし、Subversionに移動して、lockをクリックします。

次に、チェックボックスを選択します既存のロックを盗むそして[〜＃〜] ok [〜＃〜]で適用します

そのファイルをもう一度右クリックし、Subversionに移動して、ロック解除をクリックします。

コマンドラインを使用する場合：

--forceでファイルをロックします

svn lock --force path/to/file.ext

もう一度ロックを解除します

svn unlock path/to/file.ext
1
klausf

これが見つかりました： https://groups.google.com/forum/#!topic/Subversion_users/wZikmNEubz4 この問題は、1.6.17より前のsvn1.8クライアントとサーバーを使用した場合に発生するようです。作業コピーのルートフォルダーを更新すると、ロックが壊れます（needs-lockフラグに関係なく）。

1.7.14クライアントにダウングレードしましたが、問題は発生しません。

0
cmant