web-dev-qa-db-ja.com

TortoiseSVNは失敗をコミットします：「ファイルまたはディレクトリが破損していて読み取り不能です」、「読み取り専用データベースを書き込もうとしました」

Tortoisesvnを数週間使用しています。

エラーが頻繁に発生します。私がするほとんどすべてがエラーを引き起こします。これは、インターネット上のリポジトリ、ローカルの私のマシン、またはネットワーク上のマシンの場合です。それで私は追跡し始めました。いくつかの例を以下に示します。

2010年12月31日

'C：\ Users\jisaacks\Desktop\my branch test.svn\tmp\entries'を 'C：\ Users\jisaacks\Desktop\my branch test.svn\entries'に移動できません：ファイルまたはディレクトリが破損していますと読めません。

2011年1月4日

コミットに失敗しました（詳細は次のとおりです）：サーバーは、「/ svn/kranichs-svn /！svn/wrk/b316f15e-0869-4644-9c53-87aa0103506b/branchs」に対するMKCOL要求に応答して、予期しない戻り値（405メソッドは許可されていません）を送信しました

2011年1月6日

「C：\ Users\jisaacks\Desktop\DVDCatalog\vendors.svn\tmp\entries」を「C：\ Users\jisaacks\Desktop\DVDCatalog\vendors.svn\entries」に移動できません：ファイルまたはディレクトリ破損していて判読できません。

2011年1月6日

'C：\ Users\jisaacks\Desktop\DVD Catalog\cake\tests\test_app\views\layouts.svn\tmp\entries'を 'C：\ Users\jisaacks\Desktop\DVD Catalog\cake\testsに移動できません\ test_app\views\layouts.svn\entrys '：ファイルまたはディレクトリが破損していて読み取り不能です。

2011年1月6日

コミットに失敗しました（詳細は次のとおりです）：読み取り専用データベースの書き込みを試みます読み取り専用データベースの書き込みを試みます

読み取り専用データベースに関する最後の問題は、コミットするたびに発生します。作業コピーでヘッドリビジョン（7）に取り組んでいるかどうかを言います。私は変更を加えてコミットします。それは私にこのエラーを与えます。しかし、ログを見ると、リビジョン8（今行ったコミット）があることがわかりますが、まだリビジョン7のままです。したがって、コミットしたばかりの現在のリビジョンになるように更新を実行する必要があります。私はそれを明確に説明したと思います。

とにかく、これらすべてのエラーがあると思います。TSVNはこれだけ不安定なのですか、誰もがこれらの問題を抱えていますか。それとも私だけですか？私だけの場合、私は何を間違っている可能性がありますか？

svntortoise-svn
3
JD Isaacks

同僚のPCでこの問題を確認しましたが、TortoiseSVNによってダウンロードされたファイルがMicrosoft SecurityEssentialsによって破損していることが判明しました。無効にするとすぐに問題は解消され、SVNチェックアウトは問題ありませんでした。

ウイルス対策を一時的に無効にして、再試行することをお勧めします。

4
sebastianopilla

今日、私は次のエラーも受け取りました：

svn: E200031: attempt to write a readonly database

解決策（見つかった ここ ）はsvnサーバーに移動し、修正することでしたプロジェクトのdbフォルダー内のrep-cache.dbのアクセス許可（例：/ svn/my_project/db/rep-cache.db）

Rep-cache.dbは通常のlsから隠されていましたが、FileZillaで公開されていたことに注意してください。

次の2つのコマンドで問題が解決しました。

Sudo chown root:root rep-cache.db
Sudo chmod 777 rep-cache.db

これらはsafe権限ではありませんが、トリックを実行したことに注意してください。

興味深いことに、ファイルrep-cache.dbは他のプロジェクトには存在しないようです。

1
Danny Schoemann

私は同じ問題に直面しました。インターネットで検索したところ、 この記事 が見つかりました。その後、基本的に権限の問題である、svnのセットアップに使用したユーザーとは異なるユーザーとしてログに記録されていることに気付きました。

更新：記事がなくても回答が完了するように、さらに情報を追加します。

基本的に、私はrootユーザーを使用してsvnをセットアップ/インストールしましたが、多くのLinuxシステムのデフォルトユーザーはroot以外です。そのため、システムにログインしたとき、私はrootではなかったため、上記の問題が発生していました。 Sudo su、rootとしてログインする必要があり、すべてが機能しました

0
user52573