SVN-Fehler - Keine Arbeitskopie
Vor kurzem wurde unser SVN-Server geändert und wir haben einen SVN-Switch durchgeführt.
Da die Arbeitskopie sehr viele nicht versionierte Ressourcen hatte, wurde die Arbeitskopie gesperrt und wir begannen, Ordner für Ordner für alle Ordner unter svn zu wechseln, was perfekt funktioniert.
Wenn ich versuche, Dateien zu aktualisieren, erhalte ich auf der obersten Ebene des Repositorys die svn: Arbeitskopie '.' Locked Fehler und Bereinigung hilft auch nicht. Bei der Bereinigung erhalte ich solche Fehler - svn: 'content' ist kein Arbeitskopienverzeichnis
Frische Checkout ist KEINE Option. Gibt es andere Möglichkeiten, die Sperren zu bereinigen und freizugeben und den Schalter vollständig auszuführen?
EDIT: Der letzte Absatz in der Antwort von JesperE
Wenn Sie eine "keine Arbeitskopie" erhalten, wenn eine rekursive "svn-Bereinigung" meines Vermutung ist, dass Sie ein Verzeichnis haben Dies sollte eine Arbeitskopie sein (d. h. das .svn-Verzeichnis auf der obersten Ebene .__ sagt dies), aber es fehlt seine eigene .svn Verzeichnis. In diesem Fall müssen Sie könnte versuchen, das .__ einfach zu entfernen/zu verschieben. Verzeichnis und führen Sie dann ein lokales Update durch
scheint die Lösung des Problems im Repository zu sein. Ich habe diese Ordner identifiziert und eine erneute Überprüfung dieser spezifischen Ordner durchgeführt. Wow, die Sperren werden in der nachfolgenden Bereinigung freigegeben! Vielen Dank JesperE !!
Aber ich kann immer noch nicht den svn-Schalterfehler herausfinden, der jetzt etwas liest wie:
svn: Das Repository unter 'svn: //repourl/reponame/foldername' hat uuid 'm/reponame', aber das WC hat 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'
Irgendwelche Ideen ?
Wenn Sie bei einem rekursiven svn cleanup eine "keine Arbeitskopie" erhalten, vermute ich, dass Sie ein Verzeichnis haben, das eine Arbeitskopie sein soll (dh das .svn-Verzeichnis auf oberster Ebene sagt dies), jedoch fehlt das eigene .svn-Verzeichnis . In diesem Fall könnten Sie versuchen, das Verzeichnis einfach zu entfernen/verschieben und dann ein lokales Update durchzuführen (d. H. rm -rf content; svn checkout content).
Wenn Sie einen not a working copy-Fehler erhalten, bedeutet dies, dass Subversion dort kein richtiges .svn-Verzeichnis finden kann. Prüfen Sie, ob in contents ein .svn-Verzeichnis vorhanden ist.
Die ideale Lösung ist, wenn möglich, eine frische Kasse.
Ich bin auf eine andere Weise in eine ähnliche Situation (svn: 'papers' is not a working copy directory) geraten, also dachte ich, ich würde meine Schlachtgeschichte (vereinfacht) posten:
$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied
Hoppla! Berechtigungen korrigieren ... dann:
$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~ papers
$ svn cleanup
svn: 'papers' is not a working copy directory
Und selbst papers aus dem Weg zu räumen und svn up (der für das OP funktionierte) auszuführen, hat es nicht behoben. Folgendes habe ich getan:
$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers
Das hat funktioniert.
Ich habe es durch gelöst
- Kopieren Sie eine Sicherung der betroffenen Ordner
- SVN setzen die betroffenen Ordner zurück
- Fügen Sie die Dateien wieder aus der Sicherung ein
In meinem Fall lag das Problem an gelöschten .svn-Dateien.
Vielleicht haben Sie nur den Ordnerbaum kopiert und versucht, den niedrigsten Ordner hinzuzufügen.
SVN
|_
|
subfolder1
|
subfolder2 (here you get an error)
in diesem Fall müssen Sie das Verzeichnis auf der oberen Ebene festschreiben.
Problemumgehung: Umbenennen des Verzeichnisses, das nicht 'Arbeitskopie' ist Checkout/Update/Wiederherstellen dieses Verzeichnisses Verschieben Sie die Dateien aus dem umbenannten Verzeichnis in das neue Commit-Änderungen
Grund: Sie haben einige Änderungen an Dateien im .svn-Verzeichnis vorgenommen, wodurch die 'Arbeitskopie' unterbrochen wird.
Wenn Sie eine Datei in einem neuen Verzeichnis erstellt haben, verwenden Sie anstelle von 'svn add newdir/newfile' 'svn add newdir', da Sie das Verzeichnis hinzufügen müssen. Alle Dateien im Verzeichnis werden standardmäßig hinzugefügt.
Das habe ich gemacht:
- stamm umbenennen in trunk_
- erstellen Sie einen neuen Ordnerstamm
- Erneut auschecken und den Vorgang unterbrechen, nachdem nur wenige Dateien ausgecheckt wurden
- Verschieben Sie die Dateien von trunk_ in trunk
- Svn bereinigen
- Svn update durchführen. Dadurch wird der Status der Dateien aktualisiert, und alle Ihre Dateien werden versioniert.
Ich habe gerade "keine Arbeitskopie" bekommen, und der Grund war für mich der Automouter unter Unix . Nur ein neues "cd/path/to/work/directory" hat den Trick geleistet.
Das gleiche, ich musste einen 'Contrib' Ordner aktualisieren:
- Der alte Ordner wurde verschoben,
- Den neuen kopiert
- Kopierte die .svn-Ordner in jeden (in meinem Fall nur drei) neue Ordner.
In meinem Fall lag das Problem auch an gelöschten .svn-Ordnern.
Gelöst.
Ich treffe dieses Problem auch in der svn diff-Operation. Es wurde durch einen falschen Dateipfad verursacht. Sie sollten './' hinzufügen, um das aktuelle Dateiverzeichnis anzugeben.
Ich habe versucht, den Ordner .svn aus dem Unterordner in den Stammordner einzufügen. Es klappt!!!
@JesperE Erwähnt dass Sie die UUID ändern müssen. Folgendes soll Ihnen dabei helfen.
Auf SVN 1.5+ können Sie svnadmin setuuid ausführen. Sie können dann mit svnlook uuid überprüfen, ob es richtig eingestellt wurde. In früheren Versionen von SVN ist dies ein schwieriger Prozess. Siehe http://chestofbooks.com/computers/revision-control/Subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html
Außerdem sieht die UUID von "m/reponame" verdächtig aus. Ich glaube, es sollte eine hexadezimale Zahl wie die Arbeitskopie sein, daher könnte diese Aktion die Dinge insgesamt verbessern :-)
[Ich habe ursprünglich die Antwort von @ JesperE kommentiert, aber diese Antwort erstellt, um sie für die Menschen offensichtlicher und für Google hilfreicher zu machen. Ich habe meine Kommentare seitdem entfernt. ]
Ich bin gerade auf einen Fall gestoßen, in dem sich das Verzeichnis .svn auf einem NFS-Server auf einem anderen Rechner befindet und der NFS-Client den Dateisperrdienst (lockd) nicht ausgeführt hat.
svn: E155007: '/mnt/svnworkdir' is not a working copy
Dies ging nach dem Start von lockd auf dem nfs-Client-Host verloren.
Es scheint, als könnte Subversion mit einer besseren Fehlermeldung aufwarten, wenn es Probleme beim Sperren von Dateien gibt. Dies war Subversion 1.10.0
Hatte das gleiche Problem, stellte sich heraus, dass wir Slik 1.6.2 sowie Tortoise auf derselben Maschine hatten. Tortoise war aktualisiert worden (und hatte die Arbeitskopie aktualisiert), aber Slik nicht, also funktionierte Tortoise gut, aber die Befehlszeilen versagten mit:
svn: '.' ist kein Arbeitskopienverzeichnis
Sowohl das Entfernen von Tortoise als auch von Slik und das erneute Installieren von Tortoise mit Befehlszeilentools haben dieses Problem behoben.
Vor kurzem verwendete ich andere Entwickler Mac Ich hatte die gleiche Situation, Problem war; Zuerst musste ich get-Repo-Pfad zum Terminal eingeben, tat es aber nicht. Dann wird der Benutzername und das Kennwort angegeben.
Heute habe ich am Morgen dasselbe Problem /FILE_NAME/ is not a working copy gefunden, und ich habe mehr als zwei Stunden gebraucht, um es zu lösen. Nach langem RND und Google fand ich eine Lösung und das ist CHECKOUT.
CHECKOUTvonSubversionzu lokal als neues Projekt.- Ändern Sie einen Teil des Codes in der Java-Datei und COMMIT das Projekt.
- Es funktioniert für mich.
Ich hoffe es wird für Sie hilfreich sein.
svn: Das Repository unter 'svn: // repourl/reponame/foldername' hat uuid 'm/reponame', aber das WC hat 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'
Jedes Subversion-Repo hat eine eindeutige Kennung (uuid). Subversion verwendet dies, um sicherzustellen, dass das Repo beim Wechseln tatsächlich gleich ist. Sie sollten wahrscheinlich die uuid auf dem Server so ändern, dass sie dieselbe ist wie zuvor.
für mac: - checkout vom Server aus. Ein neues Fenster wird geöffnet, in dem Sie das Verzeichnis von Ihrem lokalen Computer auswählen können. Dann wird der gesamte Code in den ausgewählten Ordner gestellt
Könnte es ein ungleiches Arbeitskopierformat sein? Es wurde zwischen svn 1.4 und 1.5 geändert, und neuere Tools konvertieren das Format automatisch, aber die älteren funktionieren nicht mehr mit der konvertierten Kopie.
Sie müssen eine SVN-Basisdatei aus Ihrem Projekt gelöscht haben (dies sind schreibgeschützte Dateien). Aus diesem Grund erhalten Sie diesen Fehler.
Checken Sie ein neues Projekt erneut aus, führen Sie die Änderungen (falls vorhanden) Ihres älteren SVN-Projekts mit "Winmerge" zusammen und übernehmen Sie die Änderungen in Ihrem letzten Checkout.