Subversionでフォルダーが閉塞している

Subversionにチェックインしようとすると、「障害」とはどういう意味ですか？「閉塞」のテキストステータスの2つのフォルダが赤く表示されます。これがドキュメントのどこにあるのかわかりません。

cleanupコマンドを実行すると、「フォルダ名は作業ディレクトリではありません」と表示されます。これはVSで作成したばかりのフォルダーです。Subversionに追加しようとすると、エラーが発生します。他のすべてのフォルダは問題ありません。

.svnサブディレクトリを（SVNコマンドを経由せずに）削除または移動したときに発生するため、SVNは作業コピーのビューを破損しています。

最初にクリーンアップを試行し、それで解決しない場合は、ディレクトリを元に戻して（または更新して）、サブディレクトリ.svnフォルダーを復元します。

何が原因かわからない場合、解決策は作業コピー（ローカルにあるチェックアウト全体）を別の場所にエクスポートすることです。

tortoisesvnを使用している場合は、「バージョン管理されていないファイルをエクスポートする」オプションが表示されますが、コマンドラインからエクスポートすると、バージョン管理されたファイルのみがエクスポートされるため、バージョン管理されていないファイルを手動でコピーするのに少し面倒な作業が必要になると思います。

完了したら、クリーンな作業用コピーをチェックアウトし、エクスポートしたバックアップをその上にドロップします。バックアップに.svnフォルダーがないことは非常に重要です。

他の作業コピー内の作業コピーまたは.svnエントリを破損する何かをチェックアウトしたとき、私はこれらのエラーを見てきました。

同じ問題があり、次のように修正しました：

• 妨害されたディレクトリの名前を変更
• SVNに元の名前でディレクトリを作成しました（例：svn mkdir）
• 親フォルダを更新したので、新しく作成したディレクトリが作業コピーに表示されます
• 障害物から新しく作成されたディレクトリにファイルをコピーしてコミットしました

* nixシステムを使用している場合は、ファイルを作成していないことを確認し、SVNに追加してから削除し、同じ名前のフォルダーに置き換えます。OPの助けにはなりませんが、うまくいけば誰かのストレスを大幅に軽減できます。

これは、何らかの理由で、操作中に競合が発生したことを意味します。バージョン管理されたものと同じ名前の既存のバージョン管理されていないファイルまたはフォルダーがあるかどうかを確認します。

（Tortoise SVNクライアントのヘルプファイルから言い換え）

何もうまくいかなかったので、次のようにしました。

• バージョン管理されていないファイルとともに新しい場所にエクスポート
• 既存のフォルダの名前を変更しました
• プロジェクトのエクスポート場所からフォルダを移動しました
• 新しいフォルダの名前を変更しました
• 追加、コミット
• 名前が変更された古いフォルダを削除しました
• 新しいフォルダの名前を変更しました
• コミット

この状況を引き起こす可能性のあるシナリオにはさまざまなバリエーションがあります。以下はその一例です。

で終わった！「svn rename」コマンドを使用せずに、wwwからwww_aに名前が変更されたディレクトリにマークを付けます。

1. 元の名前が付いている現在のディレクトリの名前を、たとえばwww_bに変更します。
2. www_aの名前をwwwに戻します
3. wwwディレクトリ内で「svn update」または「svn revert」を実行してください。
4. 「svn delete」を使用せずに最新のwwwディレクトリを削除する
5. 親ディレクトリに移動し、「svn update」を発行します
6. これにより、元のwwwディレクトリが復元されます
7. 今回は「svn rename」を使用してwwwをwww_aに名前変更します
8. www_bの名前をwwwに戻します
9. 'svn add'を使用してリポジトリに追加します

この時点で正しいsvn作業ディレクトリを取得する必要があります。そして、svnディレクトリの混乱を解決する方法について、1つまたは2つ学びます。

Windowsマシンでこの問題に直面しました。

所属するプロジェクト全体をチェックアウトする前に、ディレクトリをチェックアウトしていました。それが「閉塞」の問題を引き起こしました。

私は単にそのフォルダーを削除し、（そのフォルダーの）ルートから更新を実行しました。それはうまくいきました。

クリーンアップなどのコマンドが機能しませんでした。

注意点：

1. フォルダが大きい場合、これはコストがかかります。
2. 変更があると、すべての変更が失われます。

ではごきげんよう。

Windowsでも、リポジトリディレクトリへのシンボリックリンクを作成したときに、これを確認しました。この場合、リポジトリルートは「障害物」と見なされます。ただし、これによる影響はないようです。

再現する手順：

1. レポをチェックアウトする

   svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
   

2. ディレクトリに問題がないことを確認してください

   cd plugin_dir
   svn st -u
   

   出力は

   Status against revision: 1234
   

3. シンボリックリンクを作成します（これは問題を示しています）。

   cd ..
   mklink /d link_dir plugin_dir
   cd link_dir
   svn st -u
   

   出力は

   ~           1234  .
   Status against revision: 1234
   

FTPクライアントを使用してサブディレクトリのあるフォルダーを作業コピーに貼り付けると、この問題に遭遇しました-転送ボタンを押すとすぐに失敗しました...作業方法の危険が遅すぎました。

上記のすべての提案とオンラインで見つかったその他の提案をすべて試しましたが、役に立ちませんでした。すべてのオプションで、ディレクトリがロックされ、操作を実行できないというエラーが発生しました。

私は自分のTime Machineコピーに移動し、ディレクトリを復元しました。予防策として作業コピーをクリーニングし、ファイルを適切に更新して、業務を再開しました。

外出先で同時に複数のブランチを使用することがよくあります。IIS構成での切り替えや混乱を避けるために、各ブランチを個別のフォルダーにチェックアウトします。次に、ディレクトリリンクを使用して、これらのフォルダーをIISで構成されたメインパスに接続します。

そのため、私にとって、リンクされたディレクトリには常に黄色の感嘆符があり、障害物としてマークされています。これは技術的にSVNの外で作成/移動されたためだと思います。

Webインターフェイスを介してCMS（WordPressまたはDrupal）を更新すると、ディレクトリでこの「障害」ステータスが表示されます。アプリケーションは、コードが実際にSubversionの作業コピーであることを認識していないため、プラグインを更新すると、そのプラグインが削除されますディレクトリ（ディレクトリを含む.svn）と新しいバージョンのプラグインから新しいディレクトリにドロップします。

その.svndirを取り戻すには、妨害されたdirを含むディレクトリから。でチェックアウトを行い--forceます。たとえば、plugin_dir「〜」とマークされている場合、その親ディレクトリから次のコマンドを実行します。

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

すでにそこにあるファイルはそのまま残され、チェックアウトコマンドの出力で「E」とマークされます（を実行すると「M」とマークされますsvn status）。

私はときどき戻って、アップデートで新しくなったファイルを追加しなければなりません。または、私がチェックアウトをしたときにそれらが再び現れたので、アップデートの一部として削除されるべきファイルを削除します。これらはチェックアウトで「A」とマークされていると思いますが、その後svn statusはそれらについて言及しません。

私はEclipseでこれに遭遇しました。そこでは、いくつかのファイルが赤い感嘆符でマークされていました。問題は、ソースディレクトリの迷惑な.svnフォルダーでした。.svnフォルダーを削除し、Eclipseを更新して、ファイルをチェックインできました。

これは、サブバージョンをXCodeがサポートしていないバージョンにアップグレードしたときにも発生します。

これが私がこれを解決するために見つけた最も簡単な（そして最も安全な）方法です：

1. 妨害されている問題のファイルまたはディレクトリ（または親ディレクトリ）の名前を一時的に変更します（例：「.backup」を追加）。
2. .svn名前を変更したディレクトリ内のディレクトリを削除します（該当する場合）。
3. svn revert ステップ1で名前が変更された（現在は欠落している）オブジェクト。
4. svn delete 元に戻されたオブジェクト。
5. 手順1のバックアップの名前を元の名前に戻します。
6. 名前を変更したオブジェクトを新しいオブジェクトとしてsvnに追加してチェックインします。

これは、まったく同じ名前のファイルをフォルダに置き換えたときに発生しました。古いファイルを削除して解決し、コミットしてから新しいファイルを追加します。少しハッキーですが、私のために働いた:)

妨害されたディレクトリの.svnを削除し、外部から更新しました。次に、外部のsvnコマンドがこれらのファイルを認識します。