Zablokowane foldery w Subversion

Co u licha oznacza „zablokowany”, kiedy próbujesz sprawdzić w Subversion? Widzę dwa foldery zaznaczone na czerwono ze statusem „zablokowany”. Nie rozumiem, co to oznacza nigdzie w dokumentach.

Kiedy próbuję wykonać cleanuppolecenie, otrzymuję komunikat „nazwa folderu nie jest katalogiem roboczym”. To jest folder, który właśnie utworzyłem w VS, a kiedy próbuję dodać go do Subversion, wyświetla mi się ten błąd. Wszystkie inne foldery są w porządku.

występuje po usunięciu lub przeniesieniu podkatalogów .svn (bez przechodzenia przez polecenia SVN), więc SVN ma uszkodzony widok kopii roboczej.

Spróbuj najpierw wyczyścić, a jeśli to nie rozwiąże problemu, przywróć (lub zaktualizuj) katalog, aby przywrócić podkatalogi .svn foldery.

Nie wiedząc, co to powoduje, rozwiązaniem może być wyeksportowanie kopii roboczej (całej kasy, którą masz lokalnie) do innego miejsca.

Jeśli używasz żółwia vn, masz opcję "eksportowania niewersjonowanych plików", ale myślę, że jeśli robisz to z wiersza poleceń, eksportuje tylko wersje wersjonowane, więc możesz mieć trochę pracochłonnego zadania kopiowania niewersjonowanych plików ręcznie .

Po zakończeniu sprawdź czystą kopię roboczą, a następnie upuść wyeksportowaną kopię zapasową, którą masz nad nią. Bardzo ważne jest, aby kopia zapasowa nie zawierała żadnych folderów .svn.

Widziałem te błędy wcześniej, gdy ludzie sprawdzali kopie robocze wewnątrz innych kopii roboczych lub cokolwiek innego, co uszkadza wpisy .svn.

Miałem ten sam problem i naprawiłem go w ten sposób:

• przemianowany na zasłonięty reż
• stworzył katalog z oryginalną nazwą w SVN (np. svn mkdir)
• zaktualizowałem folder nadrzędny, więc nowo utworzony katalog pojawia się w mojej kopii roboczej
• skopiował pliki z zablokowanego do nowo utworzonego katalogu i zatwierdził je

Jeśli korzystasz z systemu * nix, upewnij się, że nie utworzyłeś pliku, dodaj go do SVN, a następnie usuń, zastępując go folderem o tej samej nazwie. Nie pomaga OP, ale miejmy nadzieję, że pozwoli to komuś zaoszczędzić sporo stresu.

Oznacza to, że z jakiegoś powodu wystąpił konflikt podczas operacji. Sprawdź, czy istnieje niewersjonowany plik lub folder o takiej samej nazwie jak wersja z wersją.

(Parafrazowane z pliku pomocy klienta SVN Tortoise)

Nic nie działało, więc wykonałem następujące czynności:

• wyeksportowane z niewersjonowanymi plikami w nowej lokalizacji
• zmieniono nazwę istniejącego folderu
• przeniesiono folder z lokalizacji eksportu w projekcie
• zmieniono nazwę nowego folderu
• dodać, zatwierdzić
• usunął stary folder o zmienionej nazwie
• zmieniono nazwę nowego folderu
• popełnić

Istnieją różne warianty scenariuszy, które mogą powodować tę sytuację. Oto jeden przykład:

Skończyło się na! zaznacz w katalogu, którego nazwa została zmieniona z www na www_a bez użycia polecenia „svn rename”:

1. Zmień nazwę bieżącego katalogu, który nosi oryginalną nazwę, na przykład na www_b
2. Zmień nazwę www_a z powrotem na www
3. Upewnij się, że wykonujesz „svn update” lub „svn revert” w katalogu www
4. Usuń aktualny katalog www bez użycia funkcji „svn delete”
5. Przejdź do katalogu nadrzędnego i wydaj „svn update”
6. Spowoduje to przywrócenie oryginalnego katalogu www
7. Tym razem użyj 'svn rename', aby zmienić nazwę www na www_a
8. Zmień nazwę www_b z powrotem na www
9. Użyj „svn add”, aby dodać go do repozytorium

W tym momencie powinieneś uzyskać poprawny katalog roboczy svn. I naucz się kilku rzeczy o tym, jak rozwiązywać problemy z katalogami svn.

Napotkano ten problem na komputerze z systemem Windows.

Sprawdziłem katalog przed sprawdzeniem całego projektu, do którego należał. Wywołało to dla mnie problem „utrudniony”.

Po prostu usunąłem ten folder i uruchomiłem aktualizację z katalogu głównego (tego folderu). Działało dobrze.

Polecenia takie jak czyszczenie itp. Nie działały dla mnie.

Kilka słów przestrogi:

1. Jest to kosztowne, jeśli folder jest duży.
2. Spowoduje to utratę wszystkich zmian, jeśli takie istnieją.

Wszystkiego najlepszego.

Widziałem to również w systemie Windows, kiedy utworzyłem symboliczne łącze do katalogu repozytorium; w tym przypadku katalog główny repozytorium jest postrzegany jako „zablokowany”. Wydaje się jednak, że nie ma to żadnego wpływu.

Kroki ku reprodukcji:

1. Sprawdź swoje repozytorium

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

2. Sprawdź, czy katalog jest w porządku

   cd plugin_dir
   svn st -u
   

   Wyjście powinno być

   Status against revision: 1234
   

3. Utwórz łącze symboliczne (które pokazuje problem)

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

   Wyjście będzie

   ~           1234  .
   Status against revision: 1234
   

Napotkałem ten problem podczas wklejania folderu z podkatalogami do kopii roboczej za pomocą klienta FTP - wiedziałem, że schrzaniłem, gdy tylko kliknąłem przycisk przesyłania ... niebezpieczeństwa związane z pracą o wiele za późno.

Bezskutecznie wypróbowałem wszystkie powyższe sugestie i inne znalezione w Internecie. Każda opcja powodowała błąd, że mój katalog był zablokowany i nie można było wykonać operacji.

Wszedłem do mojej kopii Time Machine, przywróciłem katalog i było dobrze. Zapobiegawczo wyczyściłem kopię roboczą, poprawnie zaktualizowałem pliki i wróciłem do pracy.

Często mamy wiele oddziałów w podróży w tym samym czasie, aby oszczędzić mi przełączania się lub mieszania z konfiguracją IIS, sprawdzam każdą gałąź w osobnym folderze. Następnie używam łączenia katalogów, aby połączyć te foldery z powrotem ze ścieżką główną skonfigurowaną w usługach IIS.

Więc dla mnie połączony katalog zawsze ma żółty wykrzyknik i jest oznaczony jako zablokowany. Uważam, że dzieje się tak, ponieważ technicznie rzecz biorąc, został stworzony / przeniesiony poza SVN.

Otrzymuję ten stan „zablokowany” w katalogach, kiedy aktualizuję CMS (WordPress lub Drupal) przez interfejs sieciowy - aplikacja nie wie, że jej kod jest w rzeczywistości kopią roboczą Subversion, więc podczas aktualizacji wtyczki usuwa tę wtyczkę katalog (w tym .svnkatalog) i umieszcza w nowym katalogu z nowej wersji wtyczki.

Aby odzyskać ten .svnkatalog, z katalogu zawierającego zablokowany katalog. Robię kasę z --force. Na przykład, jeśli plugin_dirjest oznaczony "~", z katalogu nadrzędnego uruchamiam:

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

Wszystkie pliki, które już tam są, są pozostawione same i oznaczone jako „E” na wyjściu polecenia checkout (oznaczone jako „M”, gdy uruchamiam svn status).

Czasami muszę wrócić i dodać pliki, które były nowe wraz z aktualizacją; lub usuń pliki, które powinny zostać usunięte w ramach aktualizacji, ponieważ pojawiły się ponownie, gdy wykonałem płatność. Wydaje mi się, że przy kasie są one oznaczone jako „A”, ale później svn statuso nich nie wspomni.

Natknąłem się na to w Eclipse, gdzie niektóre pliki były oznaczone czerwonym wykrzyknikiem. Problem polegał na przypadkowym folderze .svn w katalogu źródłowym. Usunąłem folder .svn, odświeżyłem zaćmienie i mogłem zaewidencjonować pliki.

Może się to również zdarzyć, gdy zaktualizujesz swój subversion do wersji, której XCode nie obsługuje.

Oto najprostszy (i najbezpieczniejszy) sposób rozwiązania tego problemu:

1. Tymczasowo zmień nazwę nieprawidłowego pliku lub katalogu (lub katalogu nadrzędnego), który jest zablokowany (np. Dodaj „.backup”).
2. Usuń wszystkie .svnkatalogi w katalogu o zmienionej nazwie (jeśli dotyczy).
3. svn revert obiekt o zmienionej nazwie (a teraz brakujący) z kroku 1.
4. svn delete przywrócony obiekt.
5. Zmień nazwę kopii zapasowej z kroku 1 z powrotem na jej oryginalną nazwę.
6. Dodaj obiekt o zmienionej nazwie i wpisz go z powrotem do svn jako nowy obiekt.

Przyszło mi to do głowy, kiedy zastąpiłem plik folderem o dokładnie tej samej nazwie. Rozwiązany przez usunięcie starego pliku, zatwierdzenie, a następnie dodanie nowego. Trochę hacky, ale zadziałało dla mnie :)

Usunąłem .svn w zablokowanych katalogach i zaktualizowałem go z zewnątrz. Wtedy zewnętrzne polecenie svn rozpozna te pliki.