it-swarm.com.de

Wie korrigiere ich "Commit Failed. Datei xxx ist veraltet. Xxx-Pfad nicht gefunden."

Ich bin kürzlich auf ein besonders heikles Thema gestoßen, in dem es darum geht, das Ergebnis einer Fusion in Subversion zu begehen. Unser Subversion-Server ist @ 1.5.0 und mein TortoiseSVN-Client ist jetzt @ 1.6.1.

Ich versuche, einen Funktionszweig wieder in meinen Kofferraum zu integrieren. Die Zusammenführung scheint gut zu funktionieren; Das Festschreiben schlägt jedoch mit der folgenden Fehlermeldung fehl.

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.

Mein Arbeitsstamm ist auf dem neuesten Stand. Ich habe sogar einen neuen Ordner in einen anderen Ordner ausgecheckt, um sicherzugehen, dass es bei der Zusammenführung keine lokalen Probleme gab. Ich habe diesbezüglich einige Nachforschungen angestellt, und ich denke, ein Teil des Problems besteht in Benutzerfehlern. Ich denke, unsere Probleme sind:

  1. Wir hatten einige Entwickler, die vor 1.5 und einige danach mit einem Subversion-Client arbeiten. Ich glaube, dies hat das Potenzial, die Informationen zur Zusammenführung zu beschädigen.
  2. In anderen Branchen haben wir teilweise Zusammenführungen vorgenommen. Das heißt, wir haben nicht immer Zusammenführungen an der Wurzel des Zweigs durchgeführt. Dies dient dazu, die Aktualisierung von Flex und .NET in derselben Branche zu erleichtern.
  3. Wir haben zyklische (reflexive) Zusammenführungen in unserer Branche durchgeführt. Dies geschah, weil wir mehrere parallele Zweige hatten und wir unseren Zweig regelmäßig mit dem neuesten Code in trunk aktualisieren wollten.

All diese Dinge werden vom Buch/Team von Subversion ausdrücklich nicht empfohlen. Wir haben unsere Lektion gelernt und kennen jetzt die besten Praktiken. Wir müssen jedoch zuerst unsere neueste Niederlassung zusammenführen und festlegen.

Was ist der beste Weg, um die Probleme zu beheben, auf die wir stoßen?

Wäre das Löschen aller Informationen zum Zusammenführen im Stamm und im Zweig eine praktikable Lösung? Nein. Ich habe dies getan, aber es löst nicht den Fehler, der oben angezeigt wird.

42
Ryan Taylor

Ich hatte heute das gleiche Problem und habe keine Zwischenzusammenlegungen vorgenommen, so dass von Ihrem Eröffnungspostern nur die # 1 zutreffen könnte - allerdings habe ich sowohl von einem svn-Client in Ubuntu als auch von Tortoisesvn in Windows Commits gemacht. Zum Glück wurden in meinem Fall keine Änderungen am Kofferraum vorgenommen, so dass ich den Kofferraum durch den Zweig ersetzen konnte. Möglicherweise unterschiedliche svn-Versionen? Das ist ziemlich beunruhigend.

Wenn Sie die svn-Funktionen zum Verschieben/Kopieren/Löschen verwenden, obwohl in meinem Fall keine Historie verloren gegangen ist, verschob ich den Stamm und dann den Zweig in den Stamm.

2
svandragt

Ich hatte gerade dieses Problem, und die Ursache schien zu sein, dass ein Verzeichnis als Konflikt gekennzeichnet wurde. Reparieren:

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

Ich bekam dies auf 1.6.2 Server, 1.6.8 Schildkröte. Alles unter Windows, keine Zusammenführungen in diesem Zweig.

Ich habe ein Verzeichnis umbenannt und irgendwie (möglicherweise aufgrund von AnkhSVN) wurden zwei der Dateien im Verzeichnis als "ersetzt" und nicht als "normal" markiert. Es wurden einige kleinere Änderungen an anderen Dateien im Verzeichnis vorgenommen.

Durch das Zurücksetzen der als ersetzt markierten Dateien wurde das Problem behoben.

19
Simon D

Ich hatte auch das gleiche Problem und löste es mit der folgenden Methode

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

Hoffe das hilft dir :)

5
Augustine P A

Ich hatte das gleiche Problem, als ich versuchte, meine Arbeitskopie festzuschreiben. Ich habe den Ordner, den Subversion als "Pfad nicht gefunden" meldet, zur Ignorierliste hinzugefügt. Commit (sollte erfolgreich sein). Fügen Sie dann denselben Ordner wieder zu Subversion hinzu. Commit noch einmal.

4
David

Ich hatte gerade ein ähnliches Problem, aber ohne zu verzweigen oder zu verschmelzen, um das Problem zu verursachen. Mein Workaround war:

  • svn exportiert meinen Arbeitsordner (einschließlich nicht versionierter Dateien) in einen temporären Ordner.
  • benennen Sie den Arbeitsordner in eine Sicherung um.
  • svn checkout den Kofferraum.
  • kopieren Sie alle Ordner aus dem temporären Exportordner über den neuen Arbeitsordner.
  • svn begehen.

Alles scheint jetzt gut zu sein.

4
Tim Murphy

Ich weiß, dass dies ein alter Beitrag ist, aber dieses Problem tritt immer noch ziemlich häufig auf. Der einfachste Weg, den ich gefunden habe, um ihn zu lösen, ist das Umbenennen/Löschen der .svn/all-wcprops-Datei im betroffenen Ordner, Ausführen eines Updates und Festschreiben.

3
R M

Ich konnte keine befriedigende Lösung für dieses Problem finden. Ich habe jedoch eine unbefriedigende Lösung gefunden.

Ich habe alle Dateien innerhalb von trunk gelöscht und diese Änderungen übernommen. Ich exportierte dann meinen Zweigcode in den Trunk, fügte alle Dateien hinzu und machte ein großes Commit. Dies hatte den Effekt, dass mein Stamm meinen Zweig 1: 1 nachahmte (was ich sowieso wollte).

Leider entsteht dadurch eine große Kluft, da der Verlauf aller Dateien jetzt "verloren" ist. Aber aus Zeitgründen schien es keine andere Option zu geben.

Ich werde immer noch an allen Antworten interessiert sein, die andere haben könnten, da ich gerne wissen würde, was die Ursache war und wie man sie in Zukunft vermeiden kann.

1
Ryan Taylor

Hatte ein ähnliches Problem mit dem SVN 1.6.5 auf Mac 10.6.5, ein Upgrade auf SVN 1.6.9 und das Commit war erfolgreich.

1
maxwoj

Ich hatte das gleiche Problem, nachdem ich einen Zweig mit einer Menge Änderungen in meinem Kofferraum zusammengefügt hatte. Die einzigen zwei Lösungen, die ich sehen konnte, waren die svn move-Lösung von Pacifika oder das manuelle Zusammenführen der Dateien mit einem diff-Tool. Aber ich habe einen Workaround gefunden ...

Auf dem nicht funktionierenden Rechner wurde der Subversion-Client 1.6.5 ausgeführt. Ich habe genau das gleiche auf einer Maschine mit Subversion 1.5.4 gemacht und es funktionierte! Auf beiden Rechnern habe ich 1) eine saubere Überprüfung des Rumpfes durchgeführt, 2) svn merge ... und 3) svn begehen. Mein Server ist 1.5.x was das wert ist.

Hoffe das hilft jemandem.

1
Chris Mumford

Ich hatte das gleiche Problem. Ich weiß nicht, was der Grund ist, aber ich habe das Problem behoben, indem ich das Terminal eingegeben habe 

svn update

und dann verpflichte ich mich und boom es hat funktioniert!

1
George Vardikos

Oh Junge! Das sieht schlecht aus! Die einzige Option, die mir einfällt, ist, dass die Arbeitskopie beschädigt ist.

Löschen Sie die Arbeitskopie, führen Sie einen neuen Checkout aus und führen Sie die Zusammenführung erneut durch.

Wenn das nicht funktioniert, melden Sie einen Fehler.

1
Trumpi

Ich hatte das gleiche Problem, als ich versuchte, ein gelöschtes Paket zu übergeben (das verschiedene Java-Klassen enthält, aber nichts mehr aus dem Paket erforderlich war).

Meine Lösung/Problemumgehung, um das Problem zu beheben:

  • Ich habe das gesamte Paket zurückgenommen
  • zuerst den Inhalt gelöscht
  • den gelöschten Inhalt festgelegt
  • endlich habe ich das gelöschte paket erneut festgelegt (und in den meisten fällen funktionierte es :-))

Von Zeit zu Zeit war es jedoch nicht möglich, ein gelöschtes Paket (das nichts enthält) zu übergeben

Mein Workaround:

  • Ich habe eine Dummy-Klasse im Paket erstellt
  • und danach wiederholte ich die oben genannten Schritte

Mein letzter Hinweis ...

Manchmal hilft es jedoch, das Paket/Projekt noch einmal zu synchronisieren, und danach funktioniert alles wieder gut.



Zu meiner Konfiguration:

  • Eclipse Neon
  • SVN-Schnittstelle: JavaHL (JNI) 1.8.13 (r1667537)
  • VisualSVN Server Manager, Version: 3.3.1



Vielleicht könnte ich jemandem mit einem meiner Tipps helfen.

1
Chisey88

Wow, das brauchte eine Weile, um das Problem zu lösen, da ich SVN durch Eclipse verwendete. Letztendlich funktionierte für mich nur das Commit aller nicht betroffenen Dateien, das Umbenennen des Projektverzeichnisses (bei geschlossenem Eclipse) und das erneute Überprüfen des Projekts aus dem SVN. Gut, dass es jetzt richtig funktioniert!

0
David

Ich glaube, ich habe etwas Ähnliches gesehen, als Ordner auf dem Server verschoben wurden, die Arbeitskopien jedoch an die ältere SVN-Ordnerstruktur gebunden waren. Nicht sicher, ob jemand in Ihrem Koffer herumgefahren ist, bevor Sie die Möglichkeit hatten, den Zweig zusammenzuführen.

Ist das eine Möglichkeit?

0
Steve J

Ich hatte das gleiche Problem, schlug mit dem Kopf auf und stellte fest, dass ich das Verzeichnis im Verzeichnis "/" in "/ trunk" geändert hatte und den Befehl "Switch" in TortoiseSVN vergessen hatte.

0
Sworup Shakya

Danke Jamie Bullock dieses Werk für mich 

Wie in Jamie Bullock, 

Ich hatte gerade dieses Problem, und die Ursache schien zu sein, dass ein Verzeichnis als Konflikt gekennzeichnet wurde. Reparieren:

  1. svn update 
  2. svn gelöst 
  3. svn begehen
0
Taruna

Ich bezweifle es, aber vielleicht hilft es, wenn Sie svn cleanup in Ihrem Arbeitsverzeichnis ausführen.

0
Gren

Anscheinend ist SVN kein sehr zuverlässiges Programm. Ich hatte das gleiche Problem (mit SVN mit Turtoise) und löste es, indem ich den Inhalt der CS-Datei speicherte und dann 1 Revision zurücklegte. Dies zeigte Konflikte wie folgt: "<<<<<<< Dateiname meine Änderungen

======= Code aus Repository zusammengeführt Revision "

ich habe zwar nichts Besonderes getan (nur einmal eine Revision zurückgesetzt).

Ich habe den Inhalt dieser Datei durch den gespeicherten Inhalt ersetzt, gespeichert und dann über TortoiseSVN → Resolved ..__ ausgewählt. Ich konnte die Änderungen dann in das Repository übernehmen.

0
Dick

Das sieht aus wie ein Problem mit der svn:mergeinfo-Eigenschaft, die aus dem Wackel zwischen dem Zweig und dem Stamm gerät. 

Was zu den folgenden Fragen führt (verzeihen Sie meine Befehlszeilenanweisungen, da ich Schildkröte häufig benutze):

  1. Mischen Sie auf Stamm-Stammebene oder Unterordner-Ebene zusammen? Nach meiner Erfahrung ist es immer am besten, auf der Root-Ebene zu arbeiten. Auf diese Weise glaubt der gesamte Rumpf, dass er zu einem Teil zusammengefügt wurde und nicht nur zu einem Teil (dies scheint svn in 1.5.0 stark zu verwirren). 

  2. Meine nächste Frage lautet, haben Sie den --reintergrate-Parameter verwendet? Ich kann mich nie erinnern, wie ich dazu in der Schildkröte komme, aber wenn Sie von einem Ast zum Stamm zurückkehren, sollten Sie diesen Parameter verwenden.

  3. Haben Sie den Stamm mit dem Zweig zusammengeführt, bevor Sie wieder integriert wurden? Dies kann dazu beitragen, Konflikte zu entfernen, die beim Wiedervereinigen auftreten könnten.

  4. Haben Sie svn:mergeinfo-Eigenschaften in der Verzweigung, die sich nicht auf der Stammebene befinden? Das habe ich immer gefunden, verursacht Probleme. Sie können dies jederzeit herausfinden, indem Sie svn -R pg svn:mergeinfo aufrufen. Sie können dann die Positionen und Revisionen aufzeichnen, die sich unterhalb des Stammverzeichnisses befanden. Wenn Sie sie für relevant halten, verschieben Sie sie mit svn merge --record-only -r start:end <location> in das Stammverzeichnis und löschen Sie sie anschließend mit svn pd svn:mergeinfo <location> aus den untergeordneten Root-Speicherorten. Anschließend müssen Sie diese Änderungen bestätigen

  5. Wenn Sie alles fertig haben, versuchen Sie es erneut. 

0
Andrew Cox