Dlaczego dostaję konflikty drzew w Subversion?


353

Miałem gałąź swojego pnia i okresowo scalałem zmiany z mojego pnia do mojego oddziału i wszystko działało dobrze. Dzisiaj poszedłem scalić gałąź z powrotem do pnia i wszystkie pliki dodane do mojego pnia po utworzeniu mojej gałęzi zostały oznaczone jako „konflikt drzewa”. Czy istnieje sposób, aby tego uniknąć w przyszłości?

Nie sądzę, aby były one odpowiednio oflagowane.


Czy możesz podać przepis na odtworzenie tego problemu, zaczynając od pustego repozytorium?
Wim Coenen,

Postaram się znaleźć dzisiaj trochę czasu, aby zrobić nowe repo i przetestować to, uzyskać te same wyniki i wysłać z powrotem. Dzięki.
Greg

Odpowiedzi:


399

Znalazłem rozwiązanie czytając link podany przez Gary'ego (i sugeruję pójść tą drogą).

Podsumowując, aby rozwiązać konflikt drzewa, popełniając katalog roboczy z klientem SVN 1.6.x, możesz użyć:

svn resolve --accept working -R .

gdzie .jest katalog będący w konflikcie.

OSTRZEŻENIE : „Zatwierdzanie katalogu roboczego” oznacza, że ​​struktura piaskownicy będzie tą, którą popełniasz, więc jeśli na przykład usuniesz jakiś plik z piaskownicy, zostanie on również usunięty z repozytorium. Dotyczy to tylko katalogu będącego w konflikcie.

W ten sposób sugerujemy SVN rozwiązać konflikt ( --resolve), akceptując kopię roboczą wewnątrz twojej piaskownicy ( --accept working), rekurencyjnie ( -R), zaczynając od bieżącego katalogu ( .).

W TortoiseSVN wybranie „Rozwiązane” po kliknięciu prawym przyciskiem myszy faktycznie rozwiązuje ten problem.


32
W ten sposób sugerujesz svn, aby rozwiązać konflikt (--resolve), akceptując kopię roboczą wewnątrz twojej piaskownicy (--accept działa), rekurencyjnie (-R), zaczynając od bieżącego katalogu (.) HTH
gicappa

22
w TortoiseSvn wybranie „Rozwiązane” po kliknięciu prawym przyciskiem myszy faktycznie rozwiązuje ten problem.
understack

40
czy to nie ślepo akceptuje tylko kopię roboczą? Mam na myśli, że czuję, że nie jestem w stanie powiedzieć, gdzie występują problemy z tymi konfliktami, ale jeśli po prostu rozwiążę i zaakceptuję pracę, czy to nie tylko usunie pracę innych ludzi?
Parris,

10
Jedną z przyczyn tego może być to, że svn rm'dkatalog, który Twoim zdaniem nie był już potrzebny, ale ktoś inny dodał nowy plik, który jest potrzebny. Po zaktualizowaniu kopii roboczej powinieneś uzyskać konflikt drzewa. Jeśli po prostu na ślepo zaakceptujesz swoje rozwiązanie (usunięcie katalogu), usuniesz plik tej osoby. Nie ma magicznego przycisku „rób to, co należy”. Musisz zrozumieć, co robisz, dlaczego jest on w konflikcie z najnowszą wersją i jak właściwie to rozwiązać.
bambams

5
@TWiStErRob, twierdzę, że ten objaw wskazuje na problemy związane z SVN jako narzędziem kontroli wersji. Osobiście sposobem na uniknięcie tego problemu w przyszłości byłoby skorzystanie z niego git. Ponieważ prawdopodobnie nie jest to praktyczna opcja dla pytającego, najlepszym rozwiązaniem jest radzenie sobie z sytuacją opisaną w tej odpowiedzi.
Jess Telford

59

Subversion 1.6 dodało Konflikty drzew, aby uwzględnić konflikty na poziomie katalogu. Dobrym przykładem może być lokalne usunięcie pliku, a następnie aktualizacja próbuje sprowadzić zmianę tekstu w tym pliku. Innym jest, gdy masz subversion Zmień nazwę pliku, który edytujesz, ponieważ jest to akcja Dodaj / Usuń.

Blog Subversion CollabNet zawiera świetny artykuł na temat konfliktów drzew .


9
Żaden z tych przykładów nie dotyczy mojej sytuacji. Być może mój opis nie jest jasny?
Greg

33

Z mojego doświadczenia wynika, że ​​SVN tworzy konflikt drzewa, KIEDYKOLWIEK usuwam folder. Wydaje się, że nie ma powodu.

Jestem jedynym, który pracuje nad moim kodem -> usuń katalog -> zatwierdz - - konflikt!

Nie mogę się doczekać przejścia na Git .

Powinienem wyjaśnić - używam Subclipse . To prawdopodobnie problem! Znów nie mogę się doczekać zmiany ...


2
Ten sam problem z klientem wiersza poleceń SVN, więc nie jest to Eclipse.
dolmen,

3
Mam ten sam problem z NetBeans i SVN. Usuń katalog -> konflikt.
Gruber

2
Ten sam problem tutaj ... bardzo irytujący ... trzeba CZYTAĆ, aktualizować, usuwać i zatwierdzać ...
marcolopes,

1
Odkryłem świetną sztuczkę z IntelliJ Idea, kiedy dostaję konflikty drzew. Odkładam wszystkie moje zmiany (jest to to samo, co tworzenie łatki moich zmian, a następnie ich wycofywanie). Następnie robię aktualizację SVN, aby uzyskać najnowsze zmiany z Subversion. Następnie odsuwam na półkę moje zmiany (tak samo jak zastosowanie łatki) i altówkę!
ehrhardt

1
Wydaje mi się, że mam ten sam problem z użyciem klienta svn 1.7.9 na Ubuntu 12.04.4 LTS przeciwko repozytoriom Assembla.
siliconrockstar

28

Nie wiem, czy tak się dzieje, ale czasami wybieram niewłaściwy katalog do scalenia i pojawia się ten błąd, mimo że wszystkie pliki wyglądają zupełnie dobrze.

Przykład:

Scal / svn / Project / branches / some-branch / Sources to / svn / Project / trunk ---> Konflikt drzewa

Scal / svn / Project / branches / some-branch to / svn / Project / trunk ---> OK

To może być głupi błąd, ale nie zawsze jest to oczywiste, ponieważ uważasz, że jest to coś bardziej skomplikowanego.


17

Oto, co się dzieje: Tworzysz nowy plik na pniu, a następnie łączysz go ze swoim oddziałem. W zatwierdzeniu scalania ten plik zostanie utworzony również w oddziale.

Kiedy scalasz swoją gałąź z powrotem do linii głównej, SVN próbuje zrobić to samo ponownie: Widzi, że plik został utworzony w twojej gałęzi i próbuje utworzyć go w linii głównej w zatwierdzeniu scalania, ale już istnieje! To powoduje konflikt drzewa.

Sposobem na uniknięcie tego jest specjalne połączenie, reintegracja . Możesz to osiągnąć za pomocą --reintegrateprzełącznika.

Możesz o tym przeczytać w dokumentacji: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Jednak podczas scalania gałęzi z powrotem do pnia podstawowa matematyka jest zupełnie inna. Twoja gałąź funkcji jest teraz pomieszaniem zarówno zduplikowanych zmian łącza, jak i zmian gałęzi prywatnej, więc nie ma prostego ciągłego zakresu poprawek do skopiowania. Określając opcję --reintegrate, poprosisz Subversion o staranne skopiowanie tylko tych zmian, które są unikalne dla twojej gałęzi. (I w rzeczywistości robi to poprzez porównanie najnowszego drzewa pnia z najnowszym drzewem gałęzi: wynikową różnicą są zmiany w gałęzi!)

Po ponownym zintegrowaniu gałęzi wysoce wskazane jest jej usunięcie, w przeciwnym razie konflikty będą się pojawiać za każdym razem, gdy połączysz się w innym kierunku: od pnia do gałęzi. (Z dokładnie tego samego powodu, jak opisano wcześniej.)

Jest też na to sposób, ale nigdy tego nie próbowałem. Możesz przeczytać w tym poście: Reintegracja gałęzi Subversion w wersji 1.6


1
Odebrano, ponieważ --reintegrateopcja została wycofana w Subversion 1.8. Począwszy od wersji SVN 1.8 takie połączenia są automatyczne!
bahrep

8
Głosowano, ponieważ wiele osób nadal używa subwersji <1.8
juacala

Myślę, że dodanie informacji o wersji SVN do odpowiedzi byłoby w porządku.
Peter Mortensen,

1
1.8 tutaj i nie działałoby bez tego rozwiązania.
Zima

Głosowano, ponieważ odpowiada to na pytanie, dlaczego tak się dzieje.
Joshua Breeden

7

Może to być spowodowane nie używaniem wszystkich klientów w tej samej wersji.

Używanie klienta w wersji 1.5 i klienta w wersji 1.6 w tym samym repozytorium może powodować tego rodzaju problemy. (Właśnie się ugryzłem.)


4

Jeśli napotkasz konflikty drzew, które nie mają sensu, ponieważ nie edytowałeś / nie usunąłeś / nie znalazłeś się w pobliżu pliku, istnieje również duża szansa, że ​​wystąpił błąd w poleceniu scalania.

Może się zdarzyć, że wcześniej scaliłeś już szereg zmian, które uwzględniasz w bieżącym scaleniu. Na przykład w bagażniku ktoś edytował plik, a następnie zmienia jego nazwę. Jeśli w pierwszym scaleniu uwzględnisz edycję, a następnie w drugim scaleniu uwzględnisz zarówno edycję, jak i zmianę nazwy (zasadniczo usunięcie), spowoduje to również konflikt drzewa. Powodem tego jest to, że poprzednio scalona edycja pojawia się wtedy jako własna, a zatem usunięcie nie zostanie wykonane automatycznie.

Może się to zdarzyć przynajmniej w repozytoriach 1.4, nie jestem pewien, czy scalanie danych wprowadzone w 1.5 pomaga tutaj.


2

Do dzisiaj, od co najmniej 3 miesięcy temu, regularnie napotykałem setki konfliktów drzew, gdy próbowałem scalić gałąź z powrotem do pnia (używając TortoiseSVN 1.11 ). Niezależnie od tego, czy ponownie, czy nie, BTW. Używam TortoiseSVN od wersji v1, w 2004 roku i cały czas reintegrowałem gałęzie. Coś musiało się ostatnio wydarzyć?

Więc dzisiaj przeprowadziłem ten prosty eksperyment i odkryłem, co było przyczyną tych szalonych konfliktów:

  1. Rozwidliłem bagażnik @ 393;
  2. Modyfikowałem dziesiątki plików losowo, a także tworzyłem nowe;
  3. Popełniłem Teraz @ 395 (kolega wyjechał na 394, by wykonać własne rzeczy).
  4. Potem próbowałem ponownie zintegrować gałąź z powrotem do pnia, tylko przetestować; zgodnie z zaleceniem TortoiseSVN w kreatorze: „aby scalić wszystkie wersje (ponownie zintegrować), pozostaw to pole puste”. Aby to osiągnąć, kliknąłem prawym przyciskiem myszy folder trunk i wybrałem „TortoiseSVN> Scal, z / path / to / branch” i pozostawiłem pusty zakres obrotów , zgodnie z zaleceniami w oknie dialogowym.

Dyskusja: (patrz załącznik)

wszystkie wersje ... czego? Nie wiedziałem, że klient musiał odnosić się do „ wszystkich wersji celu! (Pnia)”, ponieważ podczas reintegracji tej gałęzi zobaczyłem wzmiankę „Scalanie wersji 1-HEAD”! O MÓJ BOŻE. Biedny diabeł, tutaj padniesz na śmierć. Ta gałąź urodziła się @ 393, czy nie możesz odczytać jej aktu urodzenia, na miłość boską?dlatego doszło do tak wielu konfliktów: SVN-cli robi głupie szaleństwo od wersji 1

Rozkład:

  1. W przeciwieństwie do tego, co radzi czarodziej, określ zakres obejmujący WSZYSTKIE wersje… życia oddziału! dlatego 394-HEAD ;
  2. teraz ponownie uruchom test scalania i zdobądź cygaro. ( patrz drugi załącznik).

Morał: Nie mogę zrozumieć, dlaczego wciąż nie naprawili tego błędu, ponieważ jest jeden, przepraszam. Powinienem poświęcić czas, aby to z nimi zgłosić.


1

Zetknąłem się z tym problemem również dzisiaj, chociaż mój konkretny problem prawdopodobnie nie jest związany z twoim. Po przejrzeniu listy plików zdałem sobie sprawę z tego, co zrobiłem - tymczasowo korzystałem z pliku w jednym zestawie z innego zestawu. Wprowadziłem wiele zmian i nie chciałem osierocać historii SVN, więc w moim oddziale przeniosłem plik z folderu drugiego zestawu. Nie jest to śledzone przez SVN, więc wygląda na to, że plik został usunięty, a następnie ponownie dodany. To powoduje konflikt drzew.

Rozwiązałem problem, przenosząc plik z powrotem, zatwierdzając, a następnie scalając mój oddział. Potem przeniosłem plik z powrotem. :) To chyba załatwiło sprawę.


1

Miałem podobny problem. Jedyne, co faktycznie działało dla mnie, to usunięcie konfliktu podkatalogów z:

svn delete --force ./SUB_DIR_NAME

Następnie skopiuj je ponownie z innego katalogu głównego w kopii roboczej, która je zawiera:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Więc zrób

svn cleanup

i

svn add *

Możesz otrzymać ostrzeżenia z ostatnim, ale po prostu zignoruj ​​je i wreszcie

svn ci .

0

Miałem ten sam problem i rozwiązałem go, ponownie wykonując scalanie, korzystając z tych instrukcji . Zasadniczo używa „scalania 2-URL” SVN do aktualizacji trunkdo aktualnego stanu twojej gałęzi, bez zawracania sobie głowy historią i konfliktami drzew. Uratowało mnie przed ręcznym naprawieniem 114 konfliktów drzew.

Nie jestem pewien, czy zachowuje historię tak, jak byśmy chcieli, ale w moim przypadku było warto.


5
Historia jest powodem, dla którego używamy VCS ... czy coś mi brakuje?
TWiStErRob

0

Scenariusz, na który czasami wpadam:

Załóżmy, że masz pień, z którego utworzono gałąź wydania. Po kilku zmianach w bagażniku (w szczególności utworzeniu katalogu „some-dir”), tworzysz gałąź feature / fix, którą później chcesz scalić z gałęzią wydania (ponieważ zmiany były wystarczająco małe, a funkcja / fix jest ważna do wydania) .

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Jeśli następnie spróbujesz połączyć gałąź Feature / Fix bezpośrednio z gałęzią wydania, pojawi się konflikt drzewa (nawet jeśli katalog nie istniał nawet w gałęzi Feature / Fix):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

Musisz więc jawnie scalić zatwierdzenia dokonane w linii głównej przed utworzeniem gałęzi feature / fix, która utworzyła katalog „some-dir” przed scaleniem gałęzi feature / fix.

Często zapominam, że to nie jest konieczne w git.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.