14

[私の意志に反して報奨金システムによって自動選択された回答]

私はサブクリップを使用していますが、Eclipseでフォルダーを削除してコミットしようとすると、次のエラーが発生します。

svn: Item <folder> is out of date
svn: DELETE of <folder>: 409 Conflict (http://myintranet)

コマンドラインを介した削除とコミットは正常に機能しますが、サブクリップを介して行うことの何が問題になっていますか？誰かがこの問題をもっと経験していますか？

（私はUbuntu 9.10と10.04、最後のEclipseバージョン、およびサブクリップ1.4でこの問題を経験しました-サブクリップの次のバージョンにははるかに多くのバグがあるため）

--更新：ファイルではなくフォルダを削除したとき

4

7 に答える 7

39

それはSubclipse FAQで対処されていませんか?

エラー メッセージに「期限切れ」と表示される場合は常に、リポジトリ内のアイテムのリビジョンがローカル作業コピー内のコピーよりも新しいことを意味します。解決策は常に update を実行する
ことです 。これにより、作業コピーがリポジトリで最新の状態になり、再度コミットが行われます (更新によって競合が発生しなかったと仮定して)。

  • ファイルの場合、これは通常、これがどのように、なぜ起こるのかを理解するのは非常に簡単です。
  • ただし、Subversion はフォルダのバージョン管理も行います。通常、この問題が最も頻繁に発生するのはフォルダです。
    フォルダのローカル コピーがリポジトリ内のフォルダの HEAD リビジョンにある場合を除き、Subversion では、フォルダの削除/名前変更、またはバージョン管理されたプロパティの変更を行うことはできません。

次の質問は次のようなものかもしれませ
ん。

これは有効な質問です。答えは Subversion の動作方法にあります。
ファイルへの変更をコミットすると、コミットが完了すると、作業コピー内のファイルのリビジョンがその新しいリビジョンに更新されますが、そのファイルの親フォルダーのバージョンは更新されません。
これは、そのフォルダー内の他のファイルに追加/削除が行われた可能性があり、更新を実行するまで、フォルダーは実際にはその新しいリビジョンにならないためです。
これは「混合リビジョン作業コピー」と呼ばれます。

HEAD要約すると、答えは常に更新を実行して、フォルダーまたはファイルがそのリビジョンに更新されるようにすることです。

「混合リビジョンの作業コピー」について:

特別な柔軟性の 1 つは、異なる作業リビジョン番号が混在するファイルとディレクトリを含む作業コピーを持つ機能です。

Subversion の基本的なルールの 1 つは、「プッシュ」アクションは「プル」を引き起こさないということです。
新しい変更をリポジトリに送信する準備ができたからといって、他の人から変更を受け取る準備ができているわけではありません。

実際には、svn commit を実行するたびに、作業コピーにリビジョンが混在することになります。
コミットしたばかりのものは、他のすべてよりも大きな作業リビジョンを持つものとしてマークされています。いくつかのコミットの後 (間に更新はありません)、作業コピーにはリビジョンの完全な混合が含まれます。

（そして、それが、フォルダーを削除した後続のコミットで「古い」メッセージを再現できないと私が信じている理由です。更新により、「混合リビジョン」状態が解決されました。）

混合リビジョンには制限があります

完全に最新ではないファイルまたはディレクトリの削除をコミットすることはできません。
アイテムの新しいバージョンがリポジトリに存在する場合、まだ確認していない変更を誤って破棄しないように、削除の試みは拒否されます。

于 2010-05-20T20:42:32.643 に答える
6

その前に更新すればうまくいくと思います..それは私のためにうまくいきました

于 2010-05-10T18:53:20.047 に答える
3

追加のソフトウェアをインストールせずに簡単な解決策があります。私もこの「問題」を抱えていました。あなたができることは次のとおりです。

1) SVN リポジトリ ビューを開きます 2) 削除したいフォルダに移動して削除します 3) Java ビューに戻ります 4) 実際に削除したプロジェクトのフォルダを更新します / プロジェクトを更新しても機能するはずです

私の場合、更新すると削除したファイルのみが取得されるため、これで問題は解決しました

于 2011-07-13T11:13:38.820 に答える
2

これに対する私の解決策は

  1. フォルダ内のすべてのアイテムを削除します
  2. リポジトリにコミットする
  3. フォルダをHEADに更新します
  4. Eclipseでフォルダーを削除する
  5. リポジトリにコミットする

少し面倒かもしれませんが、常に機能します

于 2011-02-22T20:39:30.063 に答える
2

トム、

TortoiseSVNを試して、プロジェクトワークスペースを手動で更新することをお勧めします。ハードドライブでプロジェクトディレクトリの場所を見つけてから、TortoiseSVN（または必要に応じてコマンドライン）を試して更新を実行します。

この問題のよくある原因は、SVNに「通知」せずにディレクトリを削除することです。たとえば、SVNを使用する代わりにオペレーティングシステムを使用してディレクトリを手動で削除すると、この問題が発生します。

subversionプラグインをインストールする前にディレクトリを削除したが、プロジェクトがリポジトリにすでに存在している場合は、この問題を実験します。この場合の解決策は、ディレクトリを再作成し、更新/コミットしてから、ディレクトリを再度削除することです。

幸運を。

于 2010-05-10T19:07:21.797 に答える
2

Subclipse にはこのような問題がたくさんあります。90% の確率で動作しますが、本来の動作をしません! 私は subclipse を使用しています。これは、eclipse に非常によく統合されているためです。svn で問題が発生したり、より大きな移動が必要な場合 (ブランチのマージなど) は、Tortoisse を使用します。

私はあなたのようなディレクトリを持っていました。次に、@luiscolorado が示唆するように TortoiseSVN を実行したところ、役に立ちました。Tortoise は非常に優れたツールです (差分、パッチの適用、パッチの取得などのための多くの優れた機能を備えています)。

今日、ファイルを削除したときに問題が発生し、誰かが同じファイルを変更しました! 次に、subclipse は競合を示します (この時点まではすべて問題ありません)。しかし、元に戻すボタンがありません (競合モードでは消えます!) ので、マージを行う必要があり、マージが機能せず、何らかのエラーがスローされます。私はわざわざ読むことはしませんでした (サブクリプスのメンテナーに読んでバグとしてファイルする必要があるかもしれません;-()、tortoisse が動作することは知っていました。

だから@Tom Brito、コマンドラインを試してTortoisseを試してから、サブクリップの変更ログを見てバグを報告することができます。subclipse は、ディレクトリの変更と更新を表示するのを忘れているだけだと思います (または、そうしないように設計されていますか?) が、間違っている可能性があります。

于 2010-11-30T15:12:30.937 に答える
0

同じ場合の唯一の作業方法は、コマンド ラインを使用することです。サブクリップはまだ完璧ではありません..

于 2010-07-29T13:08:16.583 に答える