Was soll ich tun, wenn die SVN-Bereinigung fehlschlägt?

Ich habe viele Änderungen in einem Arbeitsordner und etwas ist schief gelaufen, als ich versucht habe, ein Update durchzuführen.

Wenn ich jetzt eine 'svn-Bereinigung' herausgebe, bekomme ich:

>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control

MemPoolTests.cpp ist eine neue Datei, die ein anderer Entwickler hinzugefügt hat und die im Update heruntergefahren wurde. Es war vorher nicht in meinem Arbeitsordner vorhanden.

Kann ich irgendetwas tun, um vorwärts zu kommen, ohne eine neue Kopie des Repositorys auschecken zu müssen?

Erläuterung: Vielen Dank für die Vorschläge, das Verzeichnis aus dem Weg zu räumen und eine neue Kopie herunterzufahren. Ich weiß, dass dies eine Option ist, aber ich möchte diese vermeiden, da es viele Änderungen gibt, die mehrere Verzeichnisse tief verschachtelt sind (dies sollte ein Zweig gewesen sein ...).

Ich hoffe auf eine aggressivere Art der Bereinigung, vielleicht hat die SVN Probleme, die Datei wieder in einen bekannten Zustand zu versetzen (und ich habe versucht, die Arbeitskopie davon zu löschen ... das hat nicht geholfen).

Wenn man von vorne anfängt, ist das keine Option ...

Ich habe die Protokolldatei im .svnVerzeichnis gelöscht (ich habe auch die fehlerhafte Datei gelöscht .svn/props-base), eine Bereinigung durchgeführt und mein Update fortgesetzt.

Mit SVN 1.7 haben sich die Dinge geändert, und die beliebte Lösung zum Löschen der Protokolldatei im Verzeichnis .svn ist mit der Umstellung auf eine Datenbank-Arbeitskopie-Implementierung nicht möglich.

Folgendes schien zu funktionieren:

1. Löschen Sie das .svn-Verzeichnis für Ihre Arbeitskopie.
2. Starten Sie eine neue Kasse in einem neuen, temporären Verzeichnis.
3. Kündigen Sie die Kaufabwicklung (wir möchten nicht warten, bis alles heruntergezogen wird).
4. Führen Sie eine Bereinigung für diese abgebrochene Kaufabwicklung durch.
5. Jetzt haben wir ein neues .svn-Verzeichnis mit einer sauberen Datenbank (obwohl keine / wenige Dateien)
6. Kopieren Sie diese .svn in Ihr altes, beschädigtes Arbeitsverzeichnis.
7. Führen Sie svn update aus und es sollte Ihr neues partielles .svn-Verzeichnis mit Ihrem alten Arbeitsverzeichnis auf den neuesten Stand bringen.

Das ist alles ein wenig verwirrend, prozessmäßig. Im Wesentlichen löschen wir die beschädigte .svn und erstellen dann eine neue .svn für denselben Checkout-Pfad. Wir verschieben dann diese neue .svn in unser altes Arbeitsverzeichnis und aktualisieren sie auf das Repo.

Ich habe dies gerade in TSVN gemacht und es scheint gut zu funktionieren und erfordert kein vollständiges Auschecken und Herunterladen.

-Jody

Schau es dir an

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

Zusammenfassung des Fixes vom obigen Link (Danke an Anuj Varma)

1. Installieren Sie die SQLite-Befehlszeilen-Shell (sqlite-tools-win32) von http://www.sqlite.org/download.html

2. sqlite3 .svn/wc.db "select * from work_queue"

Das SELECT sollte Ihnen Ihren fehlerhaften Ordner / Ihre fehlerhafte Datei als Teil der Arbeitswarteschlange anzeigen. Sie müssen dieses Element aus der Arbeitswarteschlange löschen.

3. sqlite3 .svn/wc.db "delete from work_queue"

Das ist es. Jetzt können Sie die Bereinigung erneut ausführen - und es sollte funktionieren. Oder Sie können direkt mit der Aufgabe fortfahren, die Sie ausgeführt haben, bevor Sie aufgefordert werden, die Bereinigung auszuführen (Hinzufügen einer neuen Datei usw.).

Wenn alle Stricke reißen:

1. In einen neuen Ordner auschecken.
2. Kopieren Sie Ihre geänderten Dateien über.
3. Checken Sie wieder ein.
4. Komprimieren Sie den alten Ordner irgendwo (Sie wissen nie, dass Paranoia gut ist), bevor Sie ihn löschen und den neuen verwenden.

Die neueste Version (ich verwende 1.9.5) löst dieses Problem, indem Sie im Bereinigungsmenü die Option "Sperren aufheben" hinzufügen. Stellen Sie einfach sicher, dass dieses Kontrollkästchen beim Aufräumen aktiviert ist.

Diese Antwort gilt nur für Versionen vor 1.7 (danke @ ŁukaszBachman) .

Subversion speichert seine Informationen pro Ordner (in .svn). Wenn Sie also nur mit einem Unterordner arbeiten, müssen Sie nicht das gesamte Repository auschecken - nur den Ordner, der borked hat:

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

Dadurch erhalten Sie eine gute Arbeitskopie des Ordners borked, aber Ihre Änderungen werden weiterhin in borked_dir.bak gesichert. Das gleiche Prinzip gilt für Windows / TortoiseSVN.

Wenn Sie Änderungen in einem isolierten Ordner haben, schauen Sie sich die an

svn checkout -N borked_dir   # Non-recursive, but deprecated

oder

svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'

$ ls -la .svn
$ rm -f .svn/lock

Dann

$ svn update

Ich hoffe es hilft

Ich hatte genau das gleiche Problem. Ich konnte mich nicht festlegen, und die Bereinigung würde fehlschlagen.

Einsatz einen Kommandozeilen - Client konnte ich eine Fehlermeldung sehen , was anzeigt , dass es versagt , eine Datei bewegen aus .svn/propszu .svn/prop-base.

Ich habe mir die spezifische Datei angesehen und festgestellt, dass sie als schreibgeschützt markiert ist. Nachdem ich das schreibgeschützte Attribut entfernt hatte, konnte ich den Ordner bereinigen und meine Änderungen festschreiben.

Möglicherweise haben Sie ein Problem mit zwei Dateinamen, die sich nur durch Großbuchstaben unterscheiden. Wenn Sie auf dieses Problem gestoßen sind, wird das Problem durch Erstellen eines anderen Arbeitskopieverzeichnisses nicht behoben.

Aktuelle Windows-Dateisysteme (dh beschissene) machen den Unterschied zwischen Filenameund einfach nicht deutlich FILEname. Sie haben zwei mögliche Korrekturen:

1. Testen Sie auf der Plattform mit einem echten Dateisystem (Unix-basiert), benennen Sie die Datei um und übernehmen Sie Änderungen.
2. Wenn Sie mit Windows ausgestattet sind, können Sie Dateien im Eclipse SVN-Repository-Browser umbenennen, der den Unterschied erkennt, und die Datei dort umbenennen.
3. Sie können die problematischen Dateien auch remote von jedem Befehlszeilen-SVN-Client aus umbenennen svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename

Führen Sie den svn cleanupBefehl in einem Terminal aus (wenn er in Eclipse fehlschlägt, was mein Fall war):

~/path/to/svn-folder/$ svn cleanup

Ich habe verschiedene hier erklärte Lösungen ausprobiert , aber keine hat funktioniert .

Action - Team → Update auf den Kopf schlägt fehl:

svn: E155004: In '/ home / user / path / to / svn-folder' befinden sich unvollendete Arbeitselemente. Führen Sie zuerst 'svn cleanup' aus.

Action - Team → Cleanup nicht mit dem gleichen Fehler.

Lösung, die bei mir funktioniert hat: Führen Sie den Befehl svn cleanup in einem Terminal aus .

Der Befehl war erfolgreich.

Dann Team → Update funktionierte in Eclipse wieder.

Hinweis: Meine SVN-Version ist 1.9.3.

Überprüfen Sie auch Chris 'Antwort, wenn svn cleanupsie nicht funktioniert.

Ich habe versucht, svn cleanupüber die Konsole zu tun und habe eine Fehlermeldung wie:

svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.

Also habe ich diese Datei manuell erstellt (leer) und svn cleanupwieder gemacht. Diesmal war es OK.

Ich hatte das gleiche Problem. Für mich war die Ursache ein Konflikt mit EasySVN und (TortoiseSVN oder nur SVN). Ich hatte ein automatisches Update und Commit mit EasySVN (was nicht funktionierte).

Als ich dies deaktivierte, konnte ich nicht bereinigen, festschreiben oder aktualisieren. Keine der oben genannten Lösungen hat funktioniert, aber ein Neustart hat funktioniert :)

Ich hatte gerade das gleiche Problem unter Windows 7 64-Bit. Ich habe die Konsole als Administrator ausgeführt und das .svn-Verzeichnis aus dem Problemverzeichnis gelöscht (habe einen Fehler bezüglich Protokollen oder Ähnlichem erhalten, ihn aber ignoriert). Dann habe ich im Explorer das Problemverzeichnis gelöscht, das nicht mehr unter Versionskontrolle angezeigt wurde. Dann habe ich ein Update ausgeführt und die Dinge verliefen wie erwartet.

Wenn das Problem die Groß- und Kleinschreibung ist (was beim Auschecken auf einem Mac sowie unter Windows ein Problem sein kann) und Sie nicht die Möglichkeit haben, auf einem * nix-System auszuchecken, sollte Folgendes funktionieren. Hier ist der Prozess von Anfang an:

% svn co http://[domain]/svn/mortgages mortgages

(Kasse folgt… dann…)

svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory

Hier versucht SVN, zwei Dateien mit ähnlichen Namen auszuchecken, die sich nur von Fall zu Fall unterscheiden - Header_3_noBookmark.gifund Header_3_nobookmark.gif. Bei Mac-Dateisystemen wird die Groß- und Kleinschreibung standardmäßig so berücksichtigt, dass SVN in solchen Situationen erstickt. So...

% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

Wie svn cleanupwir wissen , funktioniert Laufen jedoch nicht.

% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control

spacer.gifist hier nicht das Problem ... Es kann einfach nicht über den vorherigen Fehler hinaus zur nächsten Datei verschoben werden. Also habe ich alle Dateien aus dem Verzeichnis gelöscht .svnund das SVN-Protokoll entfernt. Dadurch funktionierte die Bereinigung, sodass ich die fehlerhafte Datei auschecken und umbenennen konnte.

% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A    Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A         foo
D         Header_3_nobookmark.gif
% svn up
A    spacer.gif
A    Header_3_noBookmark.gif

Anschließend konnte ich zum Stammverzeichnis des Projekts zurückkehren und es ausführen svn up den Rest des überprüfen.

Wenn ich ähnliche Probleme habe, verwende ich rsync (Hinweis: Ich verwende Linux oder Mac OS X), um wie folgt zu helfen:

# Go to the parent directory
cd dir_above_borked

# Rename corrupted directory
mv borked_dir borked_dir.bak

# Checkout a fresh copy
svn checkout svn://... borked_dir

# Copy the modified files to the fresh checkout
# - test rsync
#   (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/

# - If all ok, run rsync for real
#   (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/

Auf diese Weise haben Sie eine neue Kasse, aber mit den gleichen Arbeitsdateien. Für mich funktioniert das immer wie ein Zauber.

Ich bin in letzter Zeit auch darauf gestoßen. Der Trick für mich war, nach Auswahl von "Aufräumen" im Popup-Optionsdialog "Sperren aufheben" und dann "OK" zu aktivieren. Es hat für mich erfolgreich aufgeräumt.

Subclipse wird durch das wirklich teuflische Sperrverhalten von Windows verwirrt. Unlocker ist dein Freund. Dadurch können gesperrte Dateien gefunden und die Sperren zwangsweise aufgehoben werden.

(Bevor Sie versuchen, Ordner zu verschieben und eine neue Kaufabwicklung durchzuführen.)

Löschen Sie den Ordner, in dem sich die betreffenden Dateien befinden - ja, sogar den .svnOrdner, und führen Sie dann einen svn cleanupOrdner ganz oben / übergeordnet aus.

Ich stand vor dem gleichen Problem. Nach einiger Suche im Internet fand der folgende Artikel . Dann wurde mir klar, dass ich als Benutzer angemeldet war, der sich von dem Benutzer unterschied, unter dem ich SVN eingerichtet hatte, ein Berechtigungsproblem im Grunde.

Wenn ich mit TortoiseSVN (Windows) auf dieses Problem stoße, gehe ich zu Cygwin und führe von dort aus die ' svn-Bereinigung ' aus. es räumt für mich richtig auf, danach funktioniert alles von TortoiseSVN.

Die Antworten hier haben mir nicht geholfen, aber bevor ich das Projekt erneut auscheckte, habe ich Eclipse geschlossen und geöffnet (Subversive ist mein SVN-Client) und das Problem ist verschwunden.

Es gilt möglicherweise nicht in allen Situationen, aber als ich kürzlich auf dieses Problem stieß, bestand mein "Fix" darin, das Subversion-Paket auf meinem System zu aktualisieren. Ich hatte 1.4.something ausgeführt, und als ich auf die neueste Version aktualisiert habe (in meinem Fall 1.6.6), funktionierte die Kaufabwicklung.

(Ich habe versucht, es erneut herunterzuladen, aber ein Auschecken in ein sauberes Verzeichnis hing immer an derselben Stelle.)

Schreibgeschützte Sperren treten manchmal auf Netzwerklaufwerken mit Windows auf. Versuchen Sie, die Verbindung zu trennen und erneut herzustellen. Dann bereinigen und aktualisieren.

Nachdem ich die meisten der hier genannten Lösungen durchgesehen hatte, wurde immer noch der Fehler angezeigt.

Das Problem war OS X ohne Berücksichtigung der Groß- und Kleinschreibung . Das Auschecken eines Verzeichnisses mit zwei Dateien mit demselben Namen, aber unterschiedlicher Groß- und Kleinschreibung verursacht ein Problem. Beispielsweise sollten sich ApproximationTest.java und Approximationtest.java nicht im selben Verzeichnis befinden. Sobald wir eine der Dateien entfernen, verschwindet das Problem.

Ich bin auf ein Problem gestoßen, bei dem SVN nach einem Update einen Ordner als in Konflikt stehend anzeigte. Seltsamerweise war dies nur über die Befehlszeile sichtbar - TortoiseSVN fand alles in Ordnung.

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup, svn revert, svn updateUndsvn resolve alle waren erfolglos bei dieser Fixierung.

Ich habe das Problem schließlich wie folgt gelöst:

• Suchen Sie im .svn-Verzeichnis nach "sub_dir".
• Verwenden Sie RC -> Eigenschaften, um das Flag "Schreibgeschützt" in der Eintragsdatei zu deaktivieren
• Öffnen Sie die Eintragsdatei und löschen Sie die Zeile "unvollendet ..." und die entsprechende Prüfsumme
• Speichern Sie das schreibgeschützte Flag und aktivieren Sie es erneut
• Wiederholen Sie diesen Vorgang für das Verzeichnis my_dir

Danach war alles in Ordnung.

Hinweis: Ich hatte keine lokalen Änderungen, daher weiß ich nicht, ob Sie in diesem Fall einem Risiko ausgesetzt wären. Ich habe die von anderen vorgeschlagene Lösch- / Aktualisierungsmethode nicht verwendet - ich bin in diesen Zustand gekommen, indem ich das im Verzeichnis my_dir / sub_dir / sub_sub_dir versucht habe (das mit denselben Symptomen begann) - also wollte ich nicht riskieren, die Dinge noch schlimmer zu machen nochmal!

Nicht ganz thematisch, aber vielleicht hilfreich, wenn jemand wie ich auf diesen Beitrag stößt.

Nein nein Nein! Wenn Sie SVN 1.7 oder höher verwenden, sollte der Bereinigungsbefehl den Job erledigen!

Ich habe auch einige Experimente durchgeführt und festgestellt, dass die Lösung (zumindest in Eclipse ) die Bereinigung nur für den in der Fehlermeldung angegebenen Ordner und nicht für das gesamte Projekt ausführt!

Ich musste sudo chmod 777 -R .die Berechtigungen ändern können. Ohnesudo würde es nicht funktionieren und mir den gleichen Fehler geben wie beim Ausführen anderer Befehle.

Jetzt können Sie svn updateoder was auch immer tun , ohne Ihr gesamtes Verzeichnis zu verschrotten und neu zu erstellen. Dies ist besonders hilfreich, da in Ihrer IDE oder Ihrem Texteditor möglicherweise bereits bestimmte Registerkarten geöffnet sind oder Synchronisierungsprobleme auftreten. Sie müssen Ihr Arbeitsverzeichnis nicht verschrotten und durch diese Methode ersetzen.

Ich habe dieses Problem gelöst, indem ich das .svn-Verzeichnis eines Kollegen in mein Verzeichnis kopiert und dann meine Arbeitskopie aktualisiert habe. Es war eine schöne, schnelle und saubere Lösung.

Die vorherige Antwort enthält einige sehr gute Vorschläge. Wenn Sie jedoch ein Problem mit TortoiseSVN unter Windows haben (ein gutes Produkt, aber ...), greifen Sie immer auf die Befehlszeile zurück und führen Sie zuerst eine einfache "svn-Bereinigung" durch.

In vielen Fällen führt der Windows-Client den Bereinigungsbefehl nicht aus, aber die Bereinigung funktioniert einwandfrei mit dem SVN-Befehlszeilenprogramm.

Bei einem ähnlichen Problem konnte das Problem durch manuelles Zusammenführen in der Repository-Synchronisierungsansicht behoben werden.

Ein Dateiname stand in Konflikt mit dem anderen und erwähnte das Problem deutlich. Durch Umbenennen der neueren Datei in einen anderen Namen wurde das Problem behoben.