web-dev-qa-db-ja.com

「コミットに失敗しました。ファイルxxxが最新ではありません。xxxパスが見つかりません。」の修正方法

私は最近、Subversionでのマージの結果をコミットすることに関して特に厄介な問題に遭遇しました。 Subversionサーバーは@ 1.5.0で、TortoiseSVNクライアントは@ 1.6.1です。

機能ブランチをトランクにマージしようとしています。マージは正常に機能するようです。ただし、コミットは次のエラーメッセージで失敗します。

Commit failed (details follow):
File 
'flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
is out of date
'/svn/ibis/!svn/wrk/531d459d-80fa-ea46-bfb4-940d79ee6d2e/visualization/trunk/source/flex/src/com/penbay/invision/portal/services/http/soap/ReportServices/GetAllBldgsParamsByRegionBySiteResultEvent.as' 
path not found
You have to update your working copy first.

私の作業用トランクは最新です。新しいフォルダを別のフォルダにチェックアウトして、マージを混乱させるようなローカルクラフトがないことを確認しました。私はこれについてさらに調査を行ったが、問題の一部はユーザーエラーだと思う。私たちの問題は次のとおりです。

  1. 1.5より前とその後にSubversionクライアントで作業をコミットする開発者がいました。これには、マージ情報が破損する可能性があると思います。
  2. 他のブランチでは、部分マージを実行しました。つまり、ブランチのルートで常にマージを実行したわけではありません。これは、同じブランチ内でFlexと.NETの取り組みを更新しやすくするためです。
  3. ブランチで循環（再帰）マージを実行しました。これは、複数の並列ブランチがあり、トランクの最新コードでブランチを定期的に更新したかったために行われました。

これらすべては、Subversionの本/チームによって明示的に推奨されるものではありません。私たちはレッスンを学び、今ではベストプラクティスを知っています。ただし、まず最新のブランチをマージしてコミットする必要があります。

直面している問題を修正する最良の方法は何ですか？

トランクとブランチのすべてのマージ情報を削除することは実行可能なソリューションでしょうか？ いいえ。これを実行しましたが、上記のエラーは解決しません。

svnmergecommit
45
Ryan Taylor

私は今日同じ問題を抱えていて、中間のマージを行っていないので、あなたの最初の投稿から＃1だけが適用されるかもしれません-しかし、私はubuntuのsvnクライアントとwindowsのtortoisesvnの両方からコミットしました。幸いなことに、トランクには変更が加えられていないため、トランクをブランチに置き換えることができました。おそらく異なるsvnバージョンですか？それはかなり心配です。

私の場合、履歴は失われませんが、svn move/copy/delete機能を使用すると、svnはトランクを移動し、svnはブランチをトランクに移動しました。

2
svandragt

この問題が発生したばかりで、原因はディレクトリが競合しているというフラグが立てられていたようです。修正するには：

svn update
svn resolved <the directory in conflict>
svn commit
26
j b

私はこれを1.6.2サーバー、1.6.8カメで取得していました。すべてWindowsで、このブランチにはマージされません。

ディレクトリの名前を変更すると、何らかの理由で（おそらくAnkhSVNによる）ディレクトリ内の2つのファイルが「通常」ではなく「置換」としてマークされていました。ディレクトリ内の他のファイルにいくつかの小さな変更が追加されました。

置換済みとしてマークされたファイルを元に戻すと、問題が修正されました。

19
Simon D

私も同じ問題を抱えていて、次の方法で同じことを解決しました

svn resolve --accept=working <FILE/FOLDER NAME>
svn cleanup
svn update <FILE/FOLDER NAME>
svn commit <FILE/FOLDER NAME> -m "Comment"

これがあなたを助けることを願っています:)

5
Augustine P A

作業コピーをコミットしようとしたときに同じ問題が発生しました。私がしたことは、Subversionが「パスが見つかりません」として報告するフォルダーを無視リストに追加することでした。コミット（成功するはずです）。次に、同じフォルダーをSubversionに追加し直します。再度コミットします。

4
David

私はちょうど同様の問題を抱えていましたが、問題を引き起こす分岐やマージはありませんでした。私の回避策は：

  • svnは、作業フォルダー（バージョン管理されていないファイルを含む）を一時フォルダーにエクスポートします。
  • 作業フォルダの名前をバックアップに変更します。
  • svnはトランクをチェックアウトします。
  • 一時エクスポートフォルダーから新しい作業フォルダーにすべてのフォルダーをコピーします。
  • sVNコミット。

すべて順調です。

4
Tim Murphy

これは古い投稿ですが、この問題はかなり頻繁に発生します。私がそれを解決するために見つけた最も簡単な方法は、影響を受けるフォルダの.svn/all-wcpropsファイルの名前を変更/削除してから、更新を実行してコミットすることです。

3
R M

私は同じ問題を抱えていましたが、その背後にある理由はわかりませんが、端末に入力して修正しました

svn update

そして、私はそれをコミットし、それがうまくいった！

2
George Vardikos

この問題に対する満足のいく解決策を見つけることができませんでした。しかし、私は不満足な解決策を見つけました。

トランク内のすべてのファイルを削除し、これらの変更をコミットしました。次に、ブランチコードをトランクにエクスポートし、すべてのファイルを追加して、大規模なコミットを行いました。これは私のトランクが1：1のブランチを模倣しているという影響がありました（とにかく欲しいものです）。

残念ながら、すべてのファイルの履歴が「失われた」ため、これにより大きな格差が生じます。しかし、時間の制約により、他の選択肢はないようでした。

根本的な原因が何であり、今後それを回避する方法を知りたいので、他の人が持つかもしれない答えに興味があります。

1
Ryan Taylor

Mac 10.6.5のSVN 1.6.5で同様の問題が発生し、SVN 1.6.9にアップグレードされ、コミットが成功しました。

1
maxwoj

ブランチに大量の変更をマージしてトランクに戻した後、同じ問題が発生しました。私が見ることができた2つの解決策は、 Pacifika によって提供されるsvn moveソリューションを実行するか、diffツールでファイルを手動でマージすることでした。しかし、私は回避策を見つけました...

動作していなかったマシンはSubversionクライアント1.6.5を実行していました。私はSubversion 1.5.4でマシン上でまったく同じことを行い、それは動作しました！両方のマシンで、1）トランクのクリーンチェックアウト、2）svn merge ...、および3）svn commitを実行しました。私のサーバーはそれが価値があるもののために1.5.xです。

これが誰かを助けることを願っています。

1
Chris Mumford

ああ少年！これは悪いようです！私が考えることができる唯一のオプションは、作業コピーが破損しているということです。

作業コピーを削除して、新しいチェックアウトを実行し、再度マージを実行してください。

それでもうまくいかない場合は、バグを記録してください。

1
Trumpi

削除されたパッケージ（さまざまなJavaクラスを含むが、パッケージからは何も必要なくなった）をコミットしようとしたときに同じ問題が発生しました。

問題を解決するための私の解決策/回避策：

  • パッケージ全体を元に戻しました
  • 最初にコンテンツを削除しました
  • 削除されたコンテンツをコミットしました
  • 最後に、削除したパッケージを再度コミットしました（ほとんどの場合で機能しました:-)）

ただし、時々、削除されたパッケージ（何も含まれていない）をコミットすることはできませんでした

私の回避策：

  • パッケージにダミークラスを作成しました
  • その後、上記の手順を繰り返しました

最後のヒント...

ただし、パッケージ/プロジェクトをもう一度同期すると、すべてが再び正常に機能するようになります。



私の構成について：

  • エクリプスネオン
  • SVNインターフェース：JavaHL（JNI）1.8.13（r1667537）
  • VisualSVN Server Manager、バージョン：3.3.1



たぶん、ヒントの1つで誰かを助けることができます。

1
Chisey88

うわー、EclipseでSVNを使用していたので、これは解決するのに時間がかかりました。最後に、私のために働いた唯一のことは、影響を受けていないファイルをすべてコミットし、（Eclipseを閉じて）プロジェクトディレクトリの名前を変更し、SVNからプロジェクトを再チェックアウトすることでした。正しく動作するようになりました！

0
David

サーバー上でフォルダーを移動したときに似たようなものを見たと思いますが、作業コピーはまだ古いSVNフォルダー構造にバインドされていました。ブランチをマージする前に、誰かがトランク内を移動したかどうかはわかりません。

それは可能ですか？

0
Steve J

私は同じ問題に遭遇し、頭を打ち、represotoryのディレクトリを「/」から「/ trunk」に変更し、TortoiseSVNで「Switch」コマンドを実行するのを忘れていたことがわかりました。

0
Sworup Shakya

ジェイミー・ブロックに感謝します

ジェイミー・ブロックによると、

この問題が発生したばかりで、原因はディレクトリが競合しているというフラグが立てられていたようです。修正するには：

  1. svn update
  2. sVN解決済み
  3. sVNコミット
0
Taruna

私はそれを疑いますが、おそらくあなたの作業ディレクトリでsvn cleanupを実行するのが助けになるでしょう。

0
Gren

どうやらSVNは非常に信頼できるプログラムではありません。私は同じ問題（TurtoiseでSVNを使用）を抱えていましたが、.csファイルのコンテンツを保存してから1リビジョン前に戻すことで解決しました。これは、次のような競合を示しました： "<<<<<<< filename filename my changes

=======リポジトリリビジョンからマージされたコード "

特別なことは何もしていません（一度リビジョンを設定し直すだけです）。

このファイルのコンテンツを保存済みのコンテンツに置き換えて保存し、TortoiseSVN→解決済みを選択しました。その後、リポジトリへの変更をコミットできます。

0
Dick

これは、ブランチとトランクの間のsvn:mergeinfoプロパティの異常から抜け出す問題のように見えます。

これは次の質問につながります（私がやったことでコマンドラインの指示を許してください）。

  1. トランクルートレベルまたはサブフォルダーレベルでマージしていますか？私の経験では、ルートレベルで行うのが常に最善です。これにより、トランク全体が一部ではなくマージされたと考えます（1.5.0ではsvnを大きく混乱させるようです）

  2. 私の次の質問は、--reintergrateパラメーターを使用していましたか？亀でこれに到達する方法を決して覚えることはできませんが、ブランチからトランクに戻るときは、このパラメーターを使用する必要があります。

  3. 再統合する前にトランクをブランチにマージしましたか？これは、マージして戻すときに表示される競合を削除するのに役立ちますか？

  4. ルートレベルにないブランチにsvn:mergeinfoプロパティがありますか？これは常に問題を引き起こすことがわかっています。これはいつでもsvn -R pg svn:mergeinfoにアクセスして見つけることができます。次に、ルートの下にあった場所とリビジョンを記録します。関連するものが見つかったら、svn merge --record-only -r start:end <location>でそれらをルートに移動し、svn pd svn:mergeinfo <location>でサブルートの場所から削除します。これらの変更をコミットする

  5. すべて完了したら、もう一度マージしてみてください。

0
Andrew Cox