"Phantom"-Verzeichnisse in einem SVN-Repository

Question

Ich habe es irgendwie geschafft, ein SVN-Repository in einen schlechten Zustand zu bringen. Ich habe ein Verzeichnis verschoben und kann es nun nicht mehr an seinem neuen Ort festschreiben.

Soweit svn status betroffen ist, ist das Verzeichnis unbekannt (der Name des Verzeichnisses lautet type ).

$ svn status
?      type

Wenn ich versuche, das Verzeichnis hinzuzufügen, sagt der Server, dass es bereits existiert.

$ svn add type
svn: warning: 'type' is already under version control

Wenn ich versuche, das Verzeichnis zu aktualisieren, ist es wieder weg.

$ svn update type
svn: '.' is not under version control

Wenn ich versuche, die Datei zu übertragen, meldet der Server, dass das alte übergeordnete Verzeichnis nicht mehr existiert.

$ svn commit type -m "Moving type"
svn: Commit failed (details follow):
svn: '/prior/trunk/src/nyu/prior/cvc3/theorem\_prover/expression' path not found

Um das Rätsel noch zu vergrößern, wird der Inhalt des Verzeichnisses als geändert markiert.

$ svn status type
A  +   type
M  +   type/IntegerType.java
M  +   type/BooleanType.java
M  +   type/Type.java
M  +   type/RationalRangeType.java
M  +   type/RationalType.java
M  +   type/IntegerRangeType.java

Wenn ich versuche, das Verzeichnis zu aktualisieren, erhalte ich folgende Meldung.

$ cd type
$ svn update
svn: Two top-level reports with no target

Das Commit aus dem Verzeichnis heraus ergibt das gleiche path not found Fehler wie oben.

Was ist los und wie kann ich das Problem beheben?

EDIT: @Rob Oxspring hat mich erwischt: Ich habe zu aggressiv Dinge in Eclipse verschoben.

UPDATE: Ich akzeptiere die Antwort von @Rob Oxspring: "Tu das nicht / fang einfach neu an" und nehme seinen Rat an. Ich wäre immer noch daran interessiert, wenn mir jemand sagen könnte: (a) was die oben genannten Fehlermeldungen mittlere und (b) wie man tatsächlich reparieren das Problem.

Answer 1

Für mich sieht es so aus type wurde mit einem Subversion-kompatiblen Kopierbefehl erstellt und dann mit einer Subversion-unkompatiblen Kopie in das aktuelle Verzeichnis verschoben. Meiner Erfahrung nach tritt so etwas typischerweise auf, wenn in Eclipse Paket-Refactoring-Operationen aneinandergereiht wurden, ohne dass dazwischen Commits stattfanden. Typischerweise geht Subversion nicht gut damit um, wenn man eine lokal kopierte/verschobene Datei oder einen Ordner kopiert/verschiebt, obwohl ich denke, dass Version 1.5 das besser handhaben könnte.

Um dies in Zukunft zu vermeiden, sollten Sie sich zwischen solchen Schritten festlegen. Wenn Sie die dazwischen liegenden Commits verbergen möchten, würde ich empfehlen, die mehrstufige Überarbeitung in einem Zweig durchzuführen und die Änderungen dann in dem einen Commit, den Sie anstreben, wieder in die Hauptlinie einzubinden.

Wenn es nicht zu viel Arbeit ist, würde ich empfehlen, zu einer sauberen Arbeitskopie zurückzukehren und Ihre Änderungen zu wiederholen und nach jedem Schritt zu bestätigen. Wenn Sie damit zufrieden sind, die Historie zu verlieren, d.h. die neue IntegerType.java überhaupt nicht mit dem alten System verbunden zu sein IntegerType.java dann könnten Sie den von BCS vorgeschlagenen Ansatz verfolgen:

• Verschieben Sie die geänderten Dateien an einen temporären Ort und entfernen Sie alle .svn Verzeichnisse
• Aktualisieren Sie Ihre Arbeitskopie in einen sauberen Arbeitszustand
• Kopieren Sie Ihre Änderungen an die gewünschte Stelle zurück
• Übertragen Sie die resultierende Arbeitskopie

Answer 2

Der einfache Weg, viele SVN-Fehler zu beheben, besteht darin, das gesamte Verzeichnis über das Betriebssystem zu verschieben, zu aktualisieren, um eine andere saubere Kopie davon zu erhalten und dann alles, was Sie geändert haben, mit einem anderen Werkzeug, WinMerge oder ähnlichem, zusammenzuführen.

Danach können Sie das tun, was Sie vorhatten, aber machen Sie es richtig :).

Answer 3

Haben Sie damit begonnen, das Verzeichnis einfach mit OS-Befehlen zu kopieren/verschieben, oder haben Sie mit SVN-Zeug angefangen? Wenn Sie die Dateien nur über das Betriebssystem kopiert haben, gibt es immer noch versteckte Ordner mit SVN-Informationen, die auf den alten Speicherort verweisen.

Answer 4

Ich würde vorschlagen, das Verzeichnis oberhalb von test zu löschen (außerhalb von subversionso mit rm o.ä.), und dann svn update dort auszuführen.

Das heißt, wenn Sie sich nicht, wie von anderen vorgeschlagen, eine völlig neue Arbeitskopie zulegen wollen, was vielleicht der sicherste Weg wäre.

Answer 5

Ich hatte gerade das gleiche Problem. Ich habe es durch Löschen der .svn Ordner aus dem betroffenen Ordner.