Blockierte Ordner in Subversion

Was zum Teufel bedeutet "behindert", wenn Sie versuchen, in Subversion einzuchecken? Ich sehe zwei Ordner in Rot mit dem Textstatus "blockiert". Ich sehe nirgendwo in den Dokumenten, was dies bedeutet.

Wenn ich den cleanupBefehl versuche , erhalte ich die Meldung "Ordnername ist kein Arbeitsverzeichnis". Dies ist ein Ordner, den ich gerade in VS erstellt habe. Wenn ich versuche, ihn zu Subversion hinzuzufügen, wird dieser Fehler angezeigt. Alle anderen Ordner sind in Ordnung.

Es tritt auf, wenn Sie die .svn-Unterverzeichnisse gelöscht oder verschoben haben (ohne SVN-Befehle zu durchlaufen), sodass SVN eine beschädigte Ansicht der Arbeitskopie hat.

Versuchen Sie zuerst eine Bereinigung. Wenn dies nicht der Fall ist, setzen Sie das Verzeichnis zurück (oder aktualisieren Sie es), um die .svn-Ordner des Unterverzeichnisses wiederherzustellen.

Ohne zu wissen, was dies verursacht, kann die Lösung darin bestehen, die Arbeitskopie (die gesamte lokale Kasse) an einen anderen Ort zu exportieren.

Wenn Sie tortoisesvn verwenden, haben Sie die Möglichkeit, "nicht versionierte Dateien zu exportieren". Wenn Sie dies jedoch über die Befehlszeile tun, werden nur versionierte Dateien exportiert, sodass Sie möglicherweise mühsam nicht versionierte Dateien manuell kopieren müssen .

Überprüfen Sie anschließend eine saubere Arbeitskopie und legen Sie das exportierte Backup darüber ab. Es ist sehr wichtig, dass das Backup keine .svn-Ordner enthält.

Ich habe diese Fehler schon einmal gesehen, als Leute Arbeitskopien in anderen Arbeitskopien ausgecheckt haben oder irgendetwas anderes, das die .svn-Einträge beschädigt.

Hatte das gleiche Problem und behebt es wie folgt:

• benannte das behinderte Verzeichnis um
• hat das Verzeichnis mit seinem ursprünglichen Namen in SVN erstellt (z. B. svn mkdir)
• Der übergeordnete Ordner wurde aktualisiert, sodass das neu erstellte Verzeichnis in meiner Arbeitskopie angezeigt wird
• kopierte die Dateien aus dem gesperrten in das neu erstellte Verzeichnis und legte sie fest

Wenn Sie sich auf einem * nix-System befinden, stellen Sie sicher, dass Sie keine Datei erstellt haben, fügen Sie sie SVN hinzu, löschen Sie sie und ersetzen Sie sie durch einen gleichnamigen Ordner. Hilft OP nicht, aber hoffentlich erspart es jemandem eine Menge Stress.

Dies bedeutet, dass aus irgendeinem Grund während der Operation ein Konflikt aufgetreten ist. Überprüfen Sie, ob eine nicht versionierte Datei oder ein Ordner mit demselben Namen wie eine versionierte vorhanden ist.

(Umschrieben aus der Hilfedatei des Tortoise SVN-Clients)

Bei mir hat nichts funktioniert, also habe ich Folgendes getan:

• Exportiert mit den nicht versionierten Dateien an einen neuen Speicherort
• benannte den vorhandenen Ordner um
• Der Ordner wurde vom Exportspeicherort im Projekt verschoben
• benannte den neuen Ordner um
• hinzufügen, festschreiben
• entfernte den alten, umbenannten Ordner
• benannte den neuen Ordner um
• verpflichten

Es gibt verschiedene Variationen von Szenarien, die diese Situation verursachen können. Hier ist ein Beispiel:

Ich endete mit dem! Markieren Sie in einem Verzeichnis, das von www in www_a umbenannt wurde, ohne den Befehl 'svn rename' zu verwenden:

1. Benennen Sie das aktuelle Verzeichnis mit dem ursprünglichen Namen um, z. B. www_b
2. Benennen Sie www_a wieder in www um
3. Stellen Sie sicher, dass Sie im Verzeichnis www 'svn update' oder 'svn revert' ausführen
4. Löschen Sie das aktuelle www-Verzeichnis ohne 'svn delete' zu verwenden.
5. Gehen Sie zum übergeordneten Verzeichnis und geben Sie 'svn update' aus.
6. Dadurch wird das ursprüngliche WWW-Verzeichnis wiederhergestellt
7. Verwenden Sie diesmal 'svn rename', um www in www_a umzubenennen
8. Benennen Sie www_b wieder in www um
9. Verwenden Sie 'svn add', um es dem Repository hinzuzufügen

Sie sollten an dieser Stelle ein korrektes SVN-Arbeitsverzeichnis erhalten. Und lernen Sie ein oder zwei Dinge, wie Sie die Verwirrung im SVN-Verzeichnis beheben können.

Dieses Problem trat auf einem Windows-Computer auf.

Ich hatte das Verzeichnis ausgecheckt, bevor ich das gesamte Projekt ausgecheckt hatte, zu dem es gehörte. Es verursachte das "behinderte" Problem für mich.

Ich habe diesen Ordner einfach gelöscht und ein Update von root (dieses Ordners) ausgeführt. Es hat gut funktioniert.

Befehle wie Aufräumen usw. haben bei mir nicht funktioniert.

Ein Wort der Vorsicht:

1. Dies ist teuer, wenn der Ordner groß ist.
2. Dadurch verlieren Sie alle Änderungen, falls vorhanden.

Alles Gute.

Ich habe dies auch unter Windows gesehen, als ich einen symbolischen Link zu einem Repository-Verzeichnis erstellt habe. In diesem Fall wird der Repository-Stamm als "blockiert" angesehen. Dies scheint jedoch keine Auswirkungen zu haben.

Schritte zum Reproduzieren:

1. Kasse dein Repo

   svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
   

2. Überprüfen Sie, ob Ihr Verzeichnis in Ordnung ist

   cd plugin_dir
   svn st -u
   

   Ausgabe sollte sein

   Status against revision: 1234
   

3. Erstellen Sie den Symlink (der das Problem zeigt)

   cd ..
   mklink /d link_dir plugin_dir
   cd link_dir
   svn st -u
   

   Ausgabe wird sein

   ~           1234  .
   Status against revision: 1234
   

Ich bin auf dieses Problem gestoßen, als ich mit meinem FTP-Client einen Ordner mit Unterverzeichnissen in meine Arbeitskopie eingefügt habe - ich wusste, dass ich es vermasselt habe, sobald ich auf die Übertragungstaste geklickt habe ... die Gefahren, viel zu spät zu arbeiten.

Ich habe alle oben genannten und andere online gefundenen Vorschläge ohne Erfolg ausprobiert. Jede Option verursachte den Fehler, dass mein Verzeichnis gesperrt war und der Vorgang nicht ausgeführt werden konnte.

Ich ging in meine Time Machine-Kopie, stellte das Verzeichnis wieder her und konnte loslegen. Ich habe die Arbeitskopie vorsichtshalber bereinigt, meine Dateien ordnungsgemäß aktualisiert und war wieder im Geschäft.

Wir haben oft mehrere Zweige gleichzeitig unterwegs. Um mir das Wechseln oder Herumspielen mit der IIS-Konfiguration zu ersparen, checke ich jeden Zweig in einem separaten Ordner aus. Ich verwende dann die Verzeichnisverknüpfung, um diese Ordner wieder mit dem in IIS konfigurierten Hauptpfad zu verbinden.

Für mich hat das verknüpfte Verzeichnis also immer einen gelben Ausruf und ist als blockiert markiert. Ich glaube, das liegt daran, dass es technisch außerhalb von SVN erstellt / verschoben wurde.

Ich erhalte diesen Status "blockiert" in Verzeichnissen, wenn ich über die Weboberfläche Aktualisierungen an einem CMS (WordPress oder Drupal) vornehme. Die Anwendung weiß nicht, dass es sich bei dem Code tatsächlich um eine Subversion-Arbeitskopie handelt. Wenn Sie also ein Plugin aktualisieren, werden die Plugins entfernt Verzeichnis (einschließlich der .svn Verzeichnisses) und legt ein neues Verzeichnis aus der neuen Version des Plugins ab.

Um dieses .svnVerzeichnis zurückzubekommen, aus dem Verzeichnis, das das blockierte Verzeichnis enthält. Ich mache eine Kasse mit --force. Wenn zum Beispiel plugin_dir"~" markiert ist, führe ich aus dem übergeordneten Verzeichnis Folgendes aus:

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

Alle bereits vorhandenen Dateien werden in Ruhe gelassen und am Ausgang des Checkout-Befehls mit "E" markiert (beim Ausführen als "M" markiert svn status).

Ich muss manchmal zurückgehen und alle Dateien hinzufügen, die mit dem Update neu waren. oder löschen Sie Dateien, die im Rahmen des Updates gelöscht werden sollen, da sie beim Auschecken wieder angezeigt wurden. Ich glaube, diese sind an der Kasse als "A" markiert, aber ein späterer svn statuswird sie nicht erwähnen.

Ich bin in Eclipse darauf gestoßen, wo einige Dateien mit einem roten Ausrufezeichen markiert waren. Das Problem war ein streunender .svn-Ordner im Quellverzeichnis. Ich habe den .svn-Ordner gelöscht, Eclipse aktualisiert und konnte die Dateien einchecken.

Dies kann auch passieren, wenn Sie Ihre Subversion auf eine Version aktualisieren, die XCode nicht unterstützt.

Hier ist der einfachste (und sicherste) Weg, den ich gefunden habe, um dieses Problem zu beheben:

1. Benennen Sie die fehlerhafte Datei oder das fehlerhafte Verzeichnis (oder ein übergeordnetes Verzeichnis), das blockiert ist, vorübergehend um (z. B. ".backup" hinzufügen).
2. Löschen Sie alle .svnVerzeichnisse im umbenannten Verzeichnis (falls zutreffend).
3. svn revert das umbenannte (und jetzt fehlende) Objekt aus Schritt 1.
4. svn delete das zurückgesetzte Objekt.
5. Benennen Sie die Sicherung von Schritt 1 wieder in ihren ursprünglichen Namen um.
6. Fügen Sie das umbenannte Objekt hinzu und checken Sie es als neues Objekt wieder in svn ein.

Dies fiel mir ein, als ich eine Datei durch einen Ordner mit genau demselben Namen ersetzte. Gelöst durch Löschen der alten Datei, Festschreiben und Hinzufügen der neuen Datei. Ein bisschen hacky, hat aber bei mir funktioniert :)

Ich habe .svn in blockierten Verzeichnissen gelöscht und von außen aktualisiert. Dann erkennt der Befehl außerhalb von svn diese Dateien.