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.
svn
merge
tree-conflict
DEfusion
źródło
źródło
Znalazłem post sugerujący rozwiązanie tego problemu . Zaraz będzie działać:
który zażąda plików wersji lokalnych jako OK.
Możesz go uruchomić dla pojedynczego pliku lub całych katalogów projektów.
źródło
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)svn resolve --accept working path/index.htmlsvn solution - zaakceptuj bazę
źródło
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.
źródło