SVN-Fehler - Keine Arbeitskopie

Kürzlich wurde unser SVN-Server geändert und wir haben einen SVN-Wechsel durchgeführt.

Da die Arbeitskopie eine große Menge nicht versionierter Ressourcen enthielt, wurde die Arbeitskopie gesperrt und wir begannen, Ordner für Ordner für alle Ordner unter svn zu wechseln, was einwandfrei funktioniert.

Auf der obersten Ebene des Repositorys erhalte ich jedoch beim Versuch, Dateien zu aktualisieren, die Datei svn: Working copy '.' gesperrter Fehler und Bereinigung helfen auch nicht. Wenn ich bereinige, erhalte ich folgende Fehler : svn: 'content' ist kein Arbeitskopieverzeichnis

Ein neuer Checkout ist überhaupt keine Option. Gibt es andere Möglichkeiten, die Sperren zu bereinigen und freizugeben und den Wechsel vollständig durchzuführen?

EDIT: Der letzte Absatz in JesperEs Antwort

Wenn Sie bei einer rekursiven "svn-Bereinigung" eine "keine Arbeitskopie" erhalten, haben Sie vermutlich ein Verzeichnis, das eine Arbeitskopie sein sollte (dh das .svn-Verzeichnis auf der obersten Ebene sagt dies aus), aber es fehlt das Verzeichnis eigenes .svn-Verzeichnis. In diesem Fall könnten Sie versuchen, dieses Verzeichnis einfach zu entfernen / zu verschieben und dann ein lokales Update durchzuführen

scheint die Lösung für das Problem im Repository zu sein. Ich habe diese Ordner identifiziert und diese spezifischen Ordner alleine neu ausgecheckt und wow, die Sperren werden bei der anschließenden Bereinigung freigegeben! Vielen Dank JesperE !!

Aber ich kann immer noch nicht den SVN-Switch-Fehler herausfinden, der jetzt so etwas wie lautet:

svn: Das Repository unter 'svn: // repourl / reponame / foldername' hat die Uuid 'm / reponame', aber das WC hat 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'.

Irgendwelche Ideen ?

Wenn Sie bei einer rekursiven svn cleanupAusführung eine "keine Arbeitskopie" erhalten , haben Sie vermutlich ein Verzeichnis, das eine Arbeitskopie sein sollte (dh das .svnVerzeichnis auf der obersten Ebene sagt dies), aber es fehlt ein eigenes .svnVerzeichnis. In diesem Fall könnten Sie versuchen, dieses Verzeichnis einfach zu entfernen / zu verschieben und dann ein lokales Update durchzuführen (dh rm -rf content; svn checkout content).

Wenn Sie eine not a working copyFehlermeldung erhalten, bedeutet dies, dass Subversion dort kein geeignetes .svnVerzeichnis finden kann. Überprüfen Sie, ob sich ein .svnVerzeichnis in befindetcontents

Die ideale Lösung ist, wenn möglich, eine neue Kasse.

Ich bin auf svn: 'papers' is not a working copy directoryandere Weise in eine ähnliche Situation geraten ( ), also dachte ich, ich würde meine Kampfgeschichte veröffentlichen (vereinfacht):

$ 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 wenn man papersaus dem Weg ging und rannte svn up(was für das OP funktionierte), konnte das nicht behoben werden. 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 gelöst durch

1. Kopieren Sie eine Sicherungskopie der betroffenen Ordner
2. SVN setzt die betroffenen Ordner zurück
3. Fügen Sie die Dateien aus der Sicherung wieder ein

In meinem Fall war das Problem auf gelöschte .svn-Dateien zurückzuführen.

Vielleicht haben Sie gerade den Ordnerbaum kopiert und versucht, den niedrigsten hinzuzufügen.

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

In diesem Fall müssen Sie das Verzeichnis auf der oberen Ebene festschreiben.

Problemumgehung: Verzeichnis umbenennen, bei dem es sich nicht um eine Arbeitskopie handelt. Auschecken / Aktualisieren / Wiederherstellen dieses Verzeichnisses erneut Verschieben von Dateien aus dem umbenannten Verzeichnis in neue Commit-Änderungen

Grund: Sie haben einige Änderungen an einigen Dateien im SVN-Verzeichnis vorgenommen. Dies führt zu einer Unterbrechung der Arbeitskopie.

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.

Ich habe gerade "keine Arbeitskopie" bekommen, und für mich war der Grund der Automouter unter Unix. Nur eine neue "CD / Pfad / zu / Arbeit / Verzeichnis" hat den Trick getan.

Ebenso musste ich einen 'Contrib'-Ordner aktualisieren:

1. Verschob den alten Ordner heraus,
2. Kopierte den neuen
3. Kopierte die .svn-Ordner in jeden (in meinem Fall nur drei) neuen Ordner.

In meinem Fall war das Problem auch auf gelöschte .svn-Ordner zurückzuführen.

Gelöst.

Ich habe versucht, den Ordner .svn vom Unterordner in den Stammordner einzufügen. Es klappt!!!

Das habe ich getan:

1. Trunk umbenennen in trunk_
2. Erstellen Sie einen neuen Ordner-Trunk
3. Erneutes Auschecken und Unterbrechen des Vorgangs, nachdem nur wenige Dateien ausgecheckt wurden
4. Verschieben Sie die Dateien von trunk_ nach trunk
5. Führen Sie eine SVN-Bereinigung durch
6. Svn-Update durchführen. Dadurch wird der Status der Dateien aktualisiert und anschließend werden alle Ihre Dateien versioniert.

Ich treffe dieses Problem auch in svn diff Operation, es wurde durch falschen Dateipfad verursacht, sollten Sie hinzufügen './', um das aktuelle Dateiverzeichnis anzugeben.

svn: Das Repository unter 'svn: // repourl / reponame / foldername' hat die 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 tatsächlich identisch ist, wenn Sie beispielsweise wechseln. Sie sollten wahrscheinlich die UUID auf dem Server so ändern, dass sie dieselbe ist wie zuvor.

Könnte es sich um eine Nichtübereinstimmung des Arbeitskopienformats handeln? Es wurde zwischen svn 1.4 und 1.5 gewechselt 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 (schreibgeschützte Dateien). Aus diesem Grund erhalten Sie diesen Fehler.

Überprüfen Sie ein neues Projekt erneut, führen Sie die Änderungen (falls vorhanden) Ihres älteren SVN-Projekts mit "Winmerge" mit einem neuen zusammen und übernehmen Sie die Änderungen in Ihrem letzten Check-out.

@JesperE erwähnt, dass Sie die UUID ändern müssen. Das Folgende 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 schwierigerer 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 hexadezimal formatierte Zahl sein, wie die der Arbeitskopie, also wird diese Aktion vielleicht die Dinge rundum verbessern :-)

[Ich habe ursprünglich die Antwort von @ JesperE kommentiert , diese Antwort jedoch erstellt, um sie für die Menschen offensichtlicher und für Google hilfreicher zu machen. Ich habe seitdem meine Kommentare entfernt. ]]

Hatte das gleiche Problem, stellte sich heraus, dass wir Slik 1.6.2 sowie Tortoise auf derselben Maschine hatten. Tortoise wurde aktualisiert (und hatte die Arbeitskopie aktualisiert), Slik jedoch nicht. Tortoise funktionierte also einwandfrei, aber die Befehlszeilen schlugen fehl mit:

svn: '.' ist kein Arbeitskopienverzeichnis

Das Entfernen von Tortoise und Slik und das erneute Installieren von Tortoise mit aktivierten Befehlszeilentools haben dies für mich behoben.

Für Mac: - Wenn Sie von der Serverseite aus zur Kasse gehen, wird ein neues Fenster geöffnet, in dem Sie das Verzeichnis auf Ihrem lokalen Computer auswählen können. Legen Sie dann den gesamten Code in den ausgewählten Ordner. Öffnen Sie dann die lokale SVN-Seite und fügen Sie das Projekt hinzu und schreiben Sie es fest

Heute habe ich das gleiche Problem /FILE_NAME/ is not a working copyam Morgen gefunden und mehr als zwei Stunden damit verbracht, es zu lösen. Nach langem RND und Google habe ich eine Lösung gefunden und das ist CHECKOUT.

1. CHECKOUTvon SUBVERSIONzu lokal als neues Projekt.
2. Ändern Sie einen Teil des Codes in der Java-Datei und verpflichten Sie das Projekt.
3. Es funktioniert für mich.

Hoffe es wird hilfreich für Sie.

Vor kurzem habe ich einen Mac anderer Entwickler verwendet. Ich hatte die gleiche Situation. Das Problem war: Zuerst musste ich get repo path to terminal eingeben, aber ich tat es nicht, als es heißt, wie ist Ihr Benutzername und Passwort.

Ich bin gerade auf einen Fall gestoßen, in dem sich das .svn-Verzeichnis auf einem NFS-Server auf einem anderen Computer befindet und der NFS-Client den Dateisperrdienst ( lockd) nicht ausgeführt hat.

svn: E155007: '/mnt/svnworkdir' is not a working copy

Dies ging weg, sobald lockdes auf dem nfs-Client-Host gestartet wurde.

Es scheint, als könnte Subversion eine bessere Fehlermeldung anzeigen, wenn Probleme beim Sperren von Dateien auftreten. Dies war Subversion 1.10.0

Ich habe eine neue Kasse aus demselben Projekt an einem anderen Speicherort erstellt, dann den .svn-Ordner daraus kopiert und durch meinen alten .svn-Ordner ersetzt. Danach wurde die SVN-Update-Funktion aufgerufen und alles wurde ordnungsgemäß auf dem neuesten Stand synchronisiert.

Löschen Sie den .svn-Ordner, der auf Ihrem lokalen Computer vorhanden ist. Drücken Sie auf das Windows-Symbol und geben Sie .svn ein. Löschen Sie den gesamten Ordner. Es hat bei mir funktioniert.