Dlaczego dostaję konflikty drzew w Subversion?

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.

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.

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 .

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 ...

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.

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

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.)

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.

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ą?

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. ( ).

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ć.

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ę.

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 .

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.

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.