SVN, jak rozwiązywać nowe konflikty drzew, gdy plik jest dodawany do dwóch gałęzi


95

Podczas łączenia kilku gałęzi (przy użyciu SVN 1.6.1), w których plik został dodany do obu gałęzi (a następnie pracowałem w tych oddzielnych gałęziach), otrzymuję jeden z nowych konfliktów drzew:

      C foo.txt
  >   local obstruction, incoming add upon merge

Potrzebuję zmian z obu gałęzi, ale konflikt drzewa nie daje mi zwykłych plików .working, .merge-left i .merge-right - co jest zrozumiałe ze względu na naturę konfliktu. Istnieje kilka takich konfliktów i takie, w których nastąpiło usunięcie tego samego pliku w każdej gałęzi, ale są one łatwe do rozwiązania.

Jak mogę rozwiązać ten problem? Książka SVN Redbean (dla wersji 1.6) nie obejmuje tej sytuacji.

Odpowiedzi:


40

Jak wspomniano w starszej wersji (2009) dokumentu projektowego „Tree Conflict” :

Konflikt XFAIL ze scalania pliku z dodatkowymi wersjami

Ten test wykonuje scalanie, które dodaje plik bez historii do istniejącego wersjonowanego pliku .
Powinien to być konflikt drzewa w pliku local obstruction, incoming add upon mergeodmiany „ ”. Naprawiono oczekiwania w r35341.

(Nawiasem mówiąc, jest to również nazywane „złymi bliźniakami” w ClearCase):
plik jest tworzony dwukrotnie (tutaj „dodawany” dwa razy) w dwóch różnych gałęziach, tworząc dwie różne historie dla dwóch różnych elementów, ale o tej samej nazwie.

Teoretycznym rozwiązaniem jest ręczne scalenie tych plików (za pomocą zewnętrznego narzędzia porównywania) w gałęzi docelowej ' B2'.

Jeśli nadal pracujesz nad gałęzią źródłową, idealnym scenariuszem byłoby usunięcie tego pliku z gałęzi źródłowej B1, scalenie z powrotem z B2do B1, aby ten plik był widoczny B1(wtedy będziesz pracować nad tym samym elementem).
Jeśli scalanie z powrotem nie jest możliwe, ponieważ scalanie odbywa się tylko od B1do B2, wówczas ręczne scalanie będzie konieczne dla każdego scalenia B1->B2.


2
Dokument projektu "konflikt drzew" jest zgniły :(
whitey04

4
Zabawne jest to, że nawet jeśli oba dodane pliki są identyczne , nadal pojawiają się jako sprzeczne. Naprawdę nie należy tego oznaczać jako konfliktu.
SantiBailors

1
@SantiBailors Tak zabawne, że umieram teraz. Umieram za mojego starego przyjaciela ...
Zima

163

Znalazłem post sugerujący rozwiązanie tego problemu . Zaraz będzie działać:

svn resolve --accept working <YourPath>

który zażąda plików wersji lokalnych jako OK.
Możesz go uruchomić dla pojedynczego pliku lub całych katalogów projektów.


2
Dzięki, to również rozwiązuje: C foo.txt> local add, nadchodzący dodatek po aktualizacji
lazysoundsystem

5
dzięki, to też zadziałało, ale musiałem to zrobić: svn solution
zaakceptuj

5
tak, potrzebujesz nazwy pliku. Akceptuje „.” (bieżący katalog). Musiałem też to zrobić rekurencyjnie, więc: „svn resolution --accept working --recursive”. rozwiązuje wszystko na korzyść kopii roboczej (niebezpieczne! Robiąc to, możesz zdmuchnąć zmiany innych ludzi, jak zawsze podczas rozwiązywania konfliktów)
Harry Wood

Używam utworzonego przeze mnie aliasu, aby wyświetlić listę wszystkich plików będących w konflikcie z drzewami: alias mtc='stat | awk "BEGIN { FS=\" \" } /^.{6}C/ { print \$NF }"' Następnie mogę użyć tego jako argumentu polecenia rozwiązywania, na przykład: svn resolve --accept working $(mtc)
Earl Jenkins,

1
Faktycznie trzeba też podać zasób np: svn resolve --accept working path/index.html
Tomasz Kuter

9

A jeśli nadchodzące zmiany są tymi, których chcesz? Nie mogę uruchomić rozwiązywania svn - zaakceptuj ich pełne

svn solution - zaakceptuj bazę


4
Myślę, że źle zrozumiałem pytanie. „base” jest w istocie odpowiednikiem „ich pełne” podczas korzystania z „svn solution”, ale nie rozwiązuje problemu. Zamiast tego podzieliłem go na dwie części: 1) Usuń mój lokalny katalog (lub plik) będący w konflikcie, 2) Scal. Powinno to przebiegać bez konfliktów, a ponieważ „nadchodzące zmiany są tymi, których chcesz”, nie przejmowałbym się usuniętymi elementami
Gabriel FT Gomes,

3

Po prostu udało mi się dość dokładnie zaklinować, próbując podążać za radą user619330 powyżej. Sytuacja była taka: (1): podczas pracy nad moją początkową gałęzią, gałąź1, dodałem kilka plików; (2) Stworzyłem nową gałąź, gałąź 2 do dalszego rozwoju, odgałęzienie jej od pnia, a następnie połączenie moich zmian z gałęzi1 (3) Współpracownik skopiował moje mody z gałęzi 1 do swojej własnej gałęzi, dodał kolejne mody, a następnie połączono z powrotem w pniu; (4) Chciałem teraz scalić najnowsze zmiany z linii głównej do mojej bieżącej gałęzi roboczej, branch2. To dotyczy svn 1.6.17.

Scalanie powodowało konflikty drzew z nowymi plikami i chciałem nową wersję z linii głównej, w której się różnią, więc z czystej kopii branch2, usunąłem svn pliki będące w konflikcie, zatwierdziłem te zmiany branch2 (tworząc w ten sposób tymczasowy wersja branch2 bez plików, o których mowa), a następnie wykonałem połączenie z pnia. Zrobiłem to, ponieważ chciałem, aby historia pasowała do wersji głównej, aby później nie mieć więcej problemów, gdy próbuję ponownie połączyć się z magistralą. Scalanie poszło dobrze, mam wersję trunkingową plików, svn st pokazuje wszystko w porządku, a następnie trafiłem na więcej konfliktów drzew podczas próby zatwierdzenia zmian, między usunięciem, które zrobiłem wcześniej, a dodaniem z scalania. Czy svn rozwiązał konflikty na korzyść mojej kopii roboczej (która teraz miała wersję trunkingową plików) i dostałem ją do zatwierdzenia.

Więc nie. Aktualizacja kolejnej kopii branch2 zaowocowała starą wersją plików (scalenie przed magistralą). Więc teraz mam dwie różne kopie robocze branch2, rzekomo zaktualizowane do tej samej wersji, z dwiema różnymi wersjami plików i obie nalegają, że są w pełni aktualne! Wyewidencjonowanie czystej kopii branch2 spowodowało powstanie starej (sprzed linii trunk) wersji plików. Aktualizuję je ręcznie do wersji trunk i zatwierdzam zmiany, wracam do mojej pierwszej kopii roboczej (z której pierwotnie przesłałem zmiany linii głównej), próbuję ją zaktualizować i teraz otrzymuję błąd sumy kontrolnej w tych plikach. Zdmuchnij katalog, o którym mowa, zdobądź nową wersję przez aktualizację i na koniec mam dobrą wersję branch2 ze zmianami linii głównej. Mam nadzieję. Caveat developer.

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.