Kiedy to zrobię svn status .
, otrzymuję to:
! C auto-complete-config.elc
> local edit, incoming delete upon update
! + C auto-complete.elc
> local edit, incoming delete upon update
! + C popup.elc
> local edit, incoming delete upon update
! + C fuzzy.elc
> local edit, incoming delete upon update
w zasadzie te pliki nie powinny znajdować się w repozytorium. Deweloper je usunął. Potem myślę, że svn rm ...
przez pomyłkę zrobiłem później (powinienem to zrobić svn update .
).
Więc teraz, kiedy to robię svn status .
, otrzymuję te komunikaty o konflikcie drzew.
Znalazłem tutaj dokument , ale nie jestem pewien, jak go „scalić” zgodnie z dokumentem.
Jak się ich pozbyć?
Myślę, że moja kopia robocza jest zsynchronizowana z repozytorium. Nie wiem, dlaczego te komunikaty są wyświetlane. Pliki te należy usunąć i są one usuwane o ile wiem wszędzie. Próbowałem svn update .
i svn revert .
nadal otrzymuję tę wiadomość, kiedy to robię svn status .
.
"local missing or deleted or moved away, incoming dir edit upon merge"
Odpowiedzi:
Krótka wersja:
Jeśli konflikt jest o katalogi zamiast plików, a następnie zastąpić
touch
zmkdir
irm
zrm -r
.Uwaga: ta sama procedura działa również w następującej sytuacji:
Długa wersja:
Dzieje się tak, gdy edytujesz plik, gdy ktoś inny go usunął i zatwierdził jako pierwszy. Jako dobry obywatel svn dokonujesz aktualizacji przed zatwierdzeniem. Teraz masz konflikt. Uświadomienie sobie, że usunięcie pliku jest właściwą rzeczą do usunięcia pliku z kopii roboczej. Zamiast zawartości svn teraz narzeka, że brakuje plików lokalnych i że istnieje aktualizacja powodująca konflikt, która ostatecznie chce usunąć pliki. Dobra robota svn.
Z
svn resolve
jakiegokolwiek powodu nie powinien działać, możesz wykonać następujące czynności:Sytuacja początkowa: brakuje plików lokalnych, aktualizacja powoduje konflikt.
Odtwórz pliki powodujące konflikt:
Jeśli konflikt jest o katalogach następnie zastąpić
touch
zmkdir
.Nowa sytuacja: lokalne pliki, które zostaną dodane do repozytorium (tak, svn, cokolwiek powiesz), aktualizacja nadal powoduje konflikt.
Przywróć pliki do stanu, w którym svn je lubi (co oznacza usunięcie):
Nowa sytuacja: lokalne pliki nie są znane svn, aktualizacja nie jest już w konflikcie.
Teraz możemy usunąć pliki:
Jeśli konflikt jest o katalogach następnie zastąpić
rm
zrm -r
.SVN nie narzeka już:
Gotowy.
źródło
svn st | grep ! | cut -f 7 -d' ' | xargs touch
jako jednegorm -r foo bar
(lubrmdir foo bar
w systemie Windows lub jeśli lubisz system Windows).Spróbuj rozwiązać konflikt za pomocą
źródło
Właśnie dostałem ten sam problem i znalazłem to
Rozwiązać problem.
Rozwiązanie SVN nie działało dla mnie:
źródło
Jeżeli nie dokonano żadnych zmian wewnątrz katalogu skonfliktowanego, można również
rm -rf conflicts_in_here/
i potemsvn up
. To zadziałało przynajmniej dla mnie.źródło
Możesz wymusić przywrócenie katalogu lokalnego do svn.
źródło
A + C path/to/dir
i> local dir edit, incoming dir delete or move upon update
Możesz więc po prostu przywrócić usunięty plik, ale pamiętaj: jeśli pracujesz nad dowolnym typem projektu z ustawionym plikiem projektu (np. IOS), przywrócenie pliku spowoduje dodanie go do struktury folderów systemowych, ale nie do struktury plików projektu. W takim przypadku mogą być wymagane dodatkowe kroki
źródło
Ten problem często występuje, gdy próbujemy scalić inne zmiany gałęzi z niewłaściwego katalogu.
Dawny:
Konflikt, który zostanie rzucony podczas jego wykonania, to:
A gdy wybierzesz q, aby wyjść z rozdzielczości , otrzymasz status:
co wyraźnie oznacza, że scalanie zawiera zmiany związane z
Branch1_SubDir
iBranch1_AnotherSubDir
, i nie można było znaleźć tych folderówBranch1_SubDir
(oczywiście katalog nie może znajdować się w samym sobie).Jak uniknąć tego problemu na pierwszym miejscu:
Najprostszą tego problemu, który pracował dla mnie:
źródło