Seltsames Problem mit Subversion - "Datei existiert bereits" beim Versuch, ein Verzeichnis neu zu erstellen, das in meinem Repository verwendet wurde

Also - ich hatte vor ein paar Revisionen ein Verzeichnis namens mysql. Ich habe es gelöscht und mich entschlossen, von vorne zu beginnen. Wenn ich jedoch versuche, das neue MySQL-Verzeichnis zu erstellen, wird weiterhin der Fehler "Datei existiert bereits" angezeigt:

support:/etc/puppet/modules# mkdir mysql
support:/etc/puppet/modules# svn add mysql/
A         mysql
support:/etc/puppet/modules# svn commit -m " Test"
Adding         modules/mysql
svn: Commit failed (details follow):
svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-r', path '/trunk/modules/mysql'
support:/etc/puppet/modules# svn delete mysql
svn: Use --force to override this restriction
svn: 'mysql' has local modifications
support:/etc/puppet/modules# svn --force delete mysql
D         mysql

Ich habe einige andere Beiträge gesehen, in denen vorgeschlagen wurde, ein Update zu erzwingen

support:/etc/puppet/modules# svn status
support:/etc/puppet/modules# svn update
At revision 11.
support:/etc/puppet/modules# svn mkdir mysql
A         mysql
support:/etc/puppet/modules# svn commit -m "Test"
Adding         modules/mysql
svn: Commit failed (details follow):
svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-s', path '/trunk/modules/mysql'

Ich hatte ein solches Problem, als ich einen Ordner (und Unterordner) löschte und sie von Grund auf neu erstellte . Sie erhalten diesen Fehler, wenn Sie Ordner manuell löschen und erneut hinzufügen (während Dateien damit anscheinend in Ordnung sind).

Nach einigem frustrierenden Herumspielen musste ich:
(mit TortoiseSVN unter Windows)

1. Verschieben Sie widersprüchliche Ordner aus der Arbeitskopie (damit ich meine laufenden Arbeiten nicht verliere).
2. Führen Sie eine svn updateDatei aus, die alte Dateien / Ordner wieder in die Arbeitskopie einfügt
3. svn delete Mappe
4. commit
5. Kopieren Sie den neuen Ordner wieder in die Arbeitskopie (stellen Sie sicher, dass Sie alle darin enthaltenen SVN-Ordner löschen).
6. commit

Leider erfordert (A) zwei Festschreibungen, und (B) verliert den Dateirevisionsverlauf, da nur das letzte erneute Hinzufügen zurückverfolgt wird (es sei denn, jemand kann erklären, wie dies behoben werden kann). Eine alternative Lösung, die diese beiden Probleme umgeht, besteht darin, die Schritte 3 und 4 zu überspringen. Das einzige Problem besteht darin, dass möglicherweise noch alte / unnötige Dateien in Ihrem Verzeichnis vorhanden sind. Sie können diese manuell löschen.

Würde gerne zusätzliche Einblicke hören, die andere dazu haben könnten.

Simon.

[Update] OK, ich hatte gerade wieder das gleiche Problem, aber der fehlerhafte Ordner befand sich NICHT im letzten Commit, sodass er updatenicht wiederhergestellt wurde. Stattdessen musste ich das Repository und deleteden fehlerhaften Ordner durchsuchen . Ich konnte dann addden Ordner wieder rein und commiterfolgreich.

Hatte ein ähnliches Problem. Um dies zu beheben, wurde vom SVN-Trunk mit der Option der Priorität lokaler Dateien aktualisiert.

svn update path/ --accept=mine-full

Nachdem Sie wie gewohnt festlegen konnten. Seien Sie natürlich vorsichtig damit.

hatte schon diese Art von Problem.

Meine Lösung war:

Löschen Sie den Ordner aus svn, aber bewahren Sie eine Kopie des Ordners irgendwo auf. Übernehmen Sie die Änderungen. Löschen Sie in der Sicherungskopie rekursiv alle darin enthaltenen .svn-Ordner. dafür könntest du rennen

#!/bin/bash

find -name '.svn' | while read directory;
do
    echo $directory;
    rm -rf "$directory";
done;

Löschen Sie das lokale Repository und checken Sie das gesamte Projekt erneut aus. Ich weiß nicht, ob ein teilweises Löschen / Auschecken ausreichend ist.

Grüße

Ich habe es geschafft, das Problem zu umgehen, indem ich zur letzten Version zurückgekehrt bin, in der sich das MySQL-Verzeichnis befand, dann den Inhalt des Verzeichnisses gelöscht, den neuen Inhalt darin abgelegt und die neuen Informationen wieder eingecheckt habe. Obwohl ich neugierig bin, ob Jeder hat eine bessere Erklärung dafür, was zum Teufel dort vor sich ging.

Dies ist ein böser ... mysteriöser Fehler und keine klare Lösung.

update / revert / commit hat in meiner Situation NICHT funktioniert. Ich hatte nichts Seltsames getan - nur ein paar SVN-Bewegungen.

Was DID für mich funktioniert hat war:

svn remove offender
svn commit
cd ..
rm -fR parent
svn up parent
cd parent
svn remove offender again
svn commit
copy offender back in (minus .svn dirs)
svn add
svn commit

Seltsamerweise. Grundsätzlich wurde das svn remove --force offenderaus irgendeinem Grund nicht vollständig entfernt. Welches ist eine Art, was die Fehlermeldung sagte. Erst durch Entfernen des Elternteils und anschließendes Aktualisieren des Elternteils wurde dies offensichtlich, da der Täter dann wieder auftauchte! svn entfernt den Täter wieder und entfernt ihn dann ordnungsgemäß.

Ich bin mir nicht sicher, ob dies Ihnen hilft, aber ich denke, wenn Sie svn add mysqlnach dem Löschen ein Verzeichnis erstellen, wird das Verzeichnis nur neu erstellt (machen Sie also kein mkdir selbst). Wenn Sie selbst ein Verzeichnis erstellen, erwartet svn ein .svn-Verzeichnis darin, da es bereits darüber Bescheid weiß.

1. Benennen Sie den neuen Pfad in temp um
2. Setzen Sie den neuen Pfad zurück (nicht temp!), damit svn nicht versucht, ihn festzuschreiben
3. Übernehmen Sie den Rest Ihrer Änderungen
4. Kopieren Sie den Pfad im Repository: svn copy -m "kopierter Pfad" -r
5. Aktualisieren Sie Ihre Arbeitskopie
6. mv alle Dateien von temporär bis zum neuen Pfad, der aus dem Update stammt
7. Übernehmen Sie Ihre lokalen Änderungen seit der Überarbeitung
8. Habt einen schönen Tag inklusive Geschichte ;-)

Ich hatte dieses Problem bei einem Projekt, das ich auf Netbeans ausführe. Ich habe einfach mit der rechten Maustaste auf die Datei geklickt und sie aktualisiert, um sie zu reparieren (nach dem SVN).

Diese Lösung verschmilzt reibungslos und verliert nicht die Geschichte:

1. Verschieben / Arbeitskopie / Täter an einen temporären Ort.
2. Führen Sie einen SVN-Checkout von SVN + SSH durch: //svn.example.com/repo/offender to / working-copy / offender.
3. Verschieben Sie Ihre Dateien manuell vom temporären Speicherort in die neue Kasse.
4. Löschen Sie den temporären Speicherort.

Ich bin heute auf dieses Problem gestoßen, als Xcode während einer Zweigzusammenführung abstürzte. Irgendwie wurde die Datei in das SVN-Repository hochgeladen, aber nicht richtig in der SVN-Datenbank aufgezeichnet. Ich habe die folgenden Befehle in dem Verzeichnis ausgeführt, in dem die Datei lokal vorhanden war:

svn revert bad.file
svn del svn://my.svnserver.com/svnDB/path/to/the/offending/file/bad.file

Dann habe ich die Datei von meinem lokalen System erneut hinzugefügt:

svn add bad.file
svn commit -m "Re adding bad.file"

Erfolg!

Diese Situation trat auf, wenn sich Objekte im Repository befinden, die durch die aktuelle Transaktion erstellt werden.

Einfaches Szenario:

1. checke ein Verzeichnis zweimal aus, als DIR1 und DIR2
2. mache 'svn mkdir test' in beiden
3. Commit von DIR1 machen
4. Versuchen Sie, DIR2 festzuschreiben (ohne svn up). SVN gibt diesen Fehler zurück

Gleiches gilt, wenn Sie dieselben Dateien aus zwei Arbeitskopien hinzufügen.

Gemäß der Lösung von Atmocreation müssen Sie jedoch nicht das gesamte Projekt erneut auschecken. Dies ist hilfreich, wenn bereits Arbeiten ausgeführt werden.

Angenommen, Sie haben eine Arbeitskopie:

/foo/

welches Verzeichnisse enthält:

/foo/bar/baz

und Sie erhalten die Fehlermeldung beim Festschreiben:

svn: File already exists: filesystem '/foo/bar'

Sichern Sie den Inhalt der Leiste irgendwo:

mkdir -p ~/tmp/code_backup
cp -r /foo/bar ~/tmp/code_backup

Löschen Sie die .svn-Steuerverzeichnisse aus der Sicherung. Stellen Sie sicher, dass Sie diesen Befehl richtig ausführen, sonst können Sie ziemlich ernsthaften Schaden anrichten !! Löschen Sie sie manuell, wenn Sie sich nicht sicher sind.

find ~/tmp/code_backup/bar -name .svn -type d -exec rm -rf {} \;

Stellen Sie sicher, dass die Kopie identisch ist:

diff -r -x .svn dist ~/tmp/code_backup/dist

Entfernen Sie das fehlerhafte Verzeichnis aus der Arbeitskopie: cd / foo rm -rf bar

Und stellen Sie es dann aus dem Repository wieder her:

cd /foo
svn update bar

Kopieren Sie die geänderten Dateien aus dem Backup zurück:

cp -r ~/tmp/code_backup/bar /foo/

Sie sollten jetzt in der Lage sein, ohne Fehler festzuschreiben.

Was Sie brauchen, ist der Befehl svn 'export'. Damit können Sie eine Datei oder einen gesamten Verzeichnisbaum in den Status einer anderen Revision in einem anderen Zweig versetzen.

Also so etwas wie

rm file #without 'svn' in front!
svn export myrepo/path/to/file@<revision> .
svn commit

Das Problem ist, dass das Auschecken auf einem Laptop stattfindet und in diesem Fall die Subversion die Offline-Synchronisation nicht bewältigen kann. Das Problem ist auf einem anderen Laptop reproduzierbar, während ich auf einem Desktop kein Problem damit habe, dasselbe Repository zu überprüfen.

Ich hoffe, diese Antwort wird Ihnen helfen. Ich habe ziemlich lange gebraucht, um das herauszufinden.